[Kamailio-Devel] [ openser-Bugs-2740437 ] PUBLISH authentication is wrong

[Jan Janak]

On 17-04 16:28, Iñaki Baz Castillo wrote:
> 2009/4/17 Jan Janak <jan at iptel.org>:
> >  CREATE TABLE credentials (
> >      auth_username VARCHAR(64) NOT NULL,
> >      did VARCHAR(64) NOT NULL DEFAULT '_default',
> >      realm VARCHAR(64) NOT NULL,
> >      password VARCHAR(28) NOT NULL DEFAULT '',
> >      flags INT NOT NULL DEFAULT '0',
> >      ha1 VARCHAR(32) NOT NULL,
> >      ha1b VARCHAR(32) NOT NULL DEFAULT '',
> >      uid VARCHAR(64) NOT NULL,
> >      KEY cred_idx (auth_username, did),
> >      KEY uid (uid),
> >      KEY did_idx (did),
> >      KEY realm_idx (realm)
> >  );
> >
> > Column 'did' is rarely used and we can ignore it, it can simply be filled with
> > the default value. Column 'uid' contains the uid of the user who is
> > authenticating.
> 
> How looks auth_username?  "alice", "alice at domainA.org" or
> "sip:alice at domainA.org"?
> How do you handle a multidomain environment? For example: how to fill
> the above table with these two users?:

auth_username contains the value of the digest username parameter and it then
depends on how you configure your phones, i.e. what they use as the value of
the digest authentication username.

>   sip:alice at domainA.org
>   sip:bob at domainB.net

It really depends on how do you choose to configure the system. First off, the
digest username does not have to be the same as the username in the sip
uri. If this is the case then the value of auth_username can be different from
the username in the SIP URI.

But it is often desirable to have the SIP username same as the digest
username, because then you can just configure the user agent with a SIP URI
and password. In this case you would store "alice" and "bob" in auth_username.

The value of the realm column will be set to the digest realm configured for
domainA.org and domainB.net. In the simplest case the digest realm will be
equivalent to the domain name, so you will have:

"alice", "domainA.org"
"bob", "domainB.net"

But, you can also decide that you want to share credentials across multiple
domains, especially if those domains are hosted on one server, then you can have:

"alice", "SIP Authentication"
"bob", "SIP Authentication"

> Also, Kamailio has an option to use domain or not (in various
> modules), so domain is checked or not (this improves the DB access in
> single-domain environments).

We do not have that anymore. Originally, in the pre-fork (the first fork)
era, I added the domain column pretty much everywhere where we had the
username column. We needed to add multi-domain support back then and we needed
to replace <username> with <username,domain> to ensure one username can be
assigned to two different people in two domains.

In SER, the pair <username,domain> has been replaced with <uid>. The uid is a
unique identifier of the user. The identifier is unique across all domains in
a multi-domain setup. The identifier can be anything, it can be a number, it
can be an identifiers generated by uuidgen, such as
9dad2756-db88-4993-bbbe-3523fdffdf30.

What then happens is this:

 1) A user authenticates with his/her digest username and digest realm, and
    if the authentication was successful, the authentication module retrieves
    the uid of the user from credentials table and stores that uid in an AVP.

 2) For inbound calls (no authentication), there is a function which
    translates the URI in the Request-URI to the UID of the user.

> > This is the unique id of the user within the system. Authentication functions
> > in SER store the value of the column in an AVP after successful authentication
> > and this is the primary ID of the user we use in other functions (we no longer
> > rely on comparing SIP URIs).
> 
> Could you show an example of usage of uid column? which value does it
> contain?

My SIP URI at iptel.org is sip:jan at iptel.org. My UID in the system is
"janakj", so in this case table credentials will contain:
  
  auth_username | realm | uid
  --------------+-----------+-------
  jan           | iptel.org | janakj

And if somebody calls sip:jan at iptel.org, the server needs to lookup my UID
in the URI table, which contains:

  scheme | username | did | uid
  -------+----------+-----------+-------
  "sip"  | jan      | iptel.org | janakj


All other tables that contain data that belong to me, such as the location
table with my contacts, only contain "janakj", so the location table has:

  uid    | contact                | ...
  -------+------------------------+----
  janakj | sip:janakj at 192.168.0.1 | ...

The big advantage of this is that I can have a dozen of SIP URIs registered in
the system and they all will reach the same contact. I can change my digest
authentication username any time I want and the system will still be able to
identify me correctly. I can change my SIP username or the whole SIP URI if I
get bothered by SPIT too much and and the system will still be able to lookup
all my data, such as accounting records, because my uid never changes.

> > Column flags contains various flags generic flags. This column is present in
> > many other tables within our schema. This column is used to store meta-data
> > about the row. For example, there is a flag that marks the row "disabled" and
> > SER would then pretend that the row does not exist. We can disable a set of
> > credentials this way without removing it from the database. Anothe flags can
> > be used to mark the row as deleted, while the actual deletion is performed by
> > a cron job. And so on. Here we would only need to make sure that the provision
> > script sets the column to a meaningful default value, so that the
> > authentication module can use the records, that's it.
> 
> This is great.
> 
> 
> > The following columns from your subscriber table are missing:
> >  * id -- We could perhaps use the uid column instead.
> 
> >  * domain -- We can use the did column instead of domain
> 
> How?

By updating provisioning tools that use the column. Instead of 'domain' they
can use 'did'.

   Jan.