kamailio/lib/srdb1/schema/uid_credentials.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE table PUBLIC "-//kamailio.org//DTD DBSchema V1.1//EN" 
  "http://kamailio.org/pub/kamailio/dbschema/dtd/1.1/dbschema.dtd" [

<!ENTITY % entities SYSTEM "entities.xml">
%entities;

]>

<table id="uid_credentials" xmlns:db="http://docbook.org/ns/docbook">
  <name>uid_credentials</name>
  <version>7</version>
  <type db="mysql">&MYSQL_TABLE_TYPE;</type>
  <description>
	Credentials table maps credentials, identified by username and realm to
	users identified by uid. Credentials can be used in digest authentication
	in SIP and/or authentication in SERWeb. In most situations credentials for
	digest authentication and SERWeb authentication are same. There are cases,
	however, where seperate credentials for SERWeb and separate credentials
	for digest authentication may be needed. One such example are setups where
	subscribers get HW user agents with locked configuration and thay do not
	know the password and are not allowed to change it. If they should be able
	to authenticate in SERWeb then they need different credentials with
	different password.
  </description>

  <column id="id">
    <name>id</name>
    <type>unsigned int</type>
    <size>&table_id_len;</size>
    <autoincrement/>
    <primary/>
    <type db="dbtext">int,auto</type>
    <description>Unique ID</description>
  </column>

  <column id="uid_credentials.auth_username">
	<name>auth_username</name>
	<type>string</type>
	<size>&user_len;</size>
	<description>
	  Credentials username. In digest authentication this is the username
	  configured in user agents, in SERWeb this is the login username.
	</description>
  </column>

  <column id="uid_credentials.did">
	<name>did</name>
	<type>string</type>
	<size>&id_len;</size>
    <default>_default</default>
	<description>
	  DID of the virtual domain the username belongs to.
	</description>
  </column>

  <column id="uid_credentials.realm">
	<name>realm</name>
	<type>string</type>
	<size>&realm_len;</size>
	<description>
	  Credentials realm. In digest authentication this is the value of digest
	  realm attribute, in SERWeb this is the part after @ in login username.
	</description>
  </column>

  <column>
	<name>password</name>
	<type>string</type>
	<default></default>
	<size>28</size>
	<description>
	  Plain text password of the subscriber, can be used for both digest (SER)
	  and SERWeb authentication.
	</description>
  </column>

  <column id="uid_credentials.flags">
	<name>flags</name>
	<type>int</type>
	<default>0</default>
	<description>
	  Flags that identify where this particular instance of credentials can be
	  used. If FOR_SER flag is set then the credentials can be used in digest
	  authentication in SIP. If FOR_SERWEB is set then the credentials can be
	  used for authentication in SERWeb. Meaning of flags is summarized in the
	  table below.
	  <db:note>
		<db:simpara>
		  Note that several flags below have no meaning in this table and are
		  only presented for completeness, because the flags column has
		  identical meaning of flags across most tables in the database.
		</db:simpara>
	  </db:note>
	  <db:table><db:title>possible credentials flags</db:title>
		<db:tgroup cols="4">
		  <db:thead>
			<db:row>
			  <db:entry>Bit</db:entry>
			  <db:entry>Hex value</db:entry>
			  <db:entry>Flag</db:entry>
			  <db:entry>Description</db:entry>
			</db:row>
		  </db:thead>
		  <db:tbody>
			<db:row>
			  <db:entry>0</db:entry>
			  <db:entry>0x00000001</db:entry>
			  <db:entry>FOR_SER</db:entry>
			  <db:entry>
				If set then SER will load the row (not applicable in this
				table).
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>1</db:entry>
			  <db:entry>0x00000002</db:entry>
			  <db:entry>DISABLED</db:entry>
			  <db:entry>
				The data represented by the row is temporarily disabled, which
				means it stays in the database but no applications use it.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>2</db:entry>
			  <db:entry>0x00000004</db:entry>
			  <db:entry>CANONICAL</db:entry>
			  <db:entry>
				The URI or domain name is canonical. When displaying the URI
				of the user or name of a domain then this entry should be
				used.  Not applicable in this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>3</db:entry>
			  <db:entry>0x00000008</db:entry>
			  <db:entry>ALLOWED_TO</db:entry>
			  <db:entry>
				The URI represented by this row can be used in The Request-URI
				or To header field. In other words the user will be reachable
				under this URI and can use it as an alias. Not applicable in
				this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>4</db:entry>
			  <db:entry>0x00000010</db:entry>
			  <db:entry>ALLOWED_FROM</db:entry>
			  <db:entry>
				The user identified by uid can use this URI in From header
				field. Not applicable in this table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>5</db:entry>
			  <db:entry>0x00000020</db:entry>
			  <db:entry>FOR_SERWEB</db:entry>
			  <db:entry>
				The data represented by the row is for SERWeb. This is
				currently used in credentials table only where the flags
				allows to keep different credentials for digest authentication
				in SIP and for SERWeb authentication. Not applicable in this
				table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>6</db:entry>
			  <db:entry>0x00000040</db:entry>
			  <db:entry>PENDING</db:entry>
			  <db:entry>
				The account owning the piece of data has not been activated
				yet. Not applicable in this table, this is mainly used in
				credentials table.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>7</db:entry>
			  <db:entry>0x00000100</db:entry>
			  <db:entry>DELETED</db:entry>
			  <db:entry>
				The row has been scheduled for deletion.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>8</db:entry>
			  <db:entry>0x00000200</db:entry>
			  <db:entry>CALLER_DELETED</db:entry>
			  <db:entry>
				The accounting record has been scheduled for deletion by the
				caller. The row can be deleted once both the caller and callee
				schedule the record for deletion. A single record can be
				shared by two users and thus both of them must schedule it for
				deletion before it can be physically deleted.
			  </db:entry>
			</db:row>
			<db:row>
			  <db:entry>9</db:entry>
			  <db:entry>0x00000400</db:entry>
			  <db:entry>CALLEE_DELETED</db:entry>
			  <db:entry>
				The accounting record has been scheduled for deletion by the
				callee. The row can be deleted once both the caller and callee
				schedule the record for deletion. A single record can be
				shared by two users and thus both of them must schedule it for
				deletion before it can be physically deleted.
			  </db:entry>
			</db:row>
		  </db:tbody>
		</db:tgroup>
	  </db:table>
	</description>
  </column>

  <column>
	<name>ha1</name>
	<type>string</type>
	<size>32</size>
	<description>
	  For digest authentication only. This is the H(A1) value calculated as
	  per RFC2617. The value contains an MD5 hash of string concatenated from
	  username,realm, and password: MD5(username:realm:password).
	</description>
  </column>

  <column>
	<name>ha1b</name>
	<type>string</type>
	<default></default>
	<size>32</size>
	<description>
	  Similar to ha1, but username@domain is used as username. This is
	  necessary for user agents that put username@domain into digest username
	  attribute. This is often useful in multi-domain setups because it allows
	  users to explicitly specify the domain they wish to sign in.
	</description>
  </column>

  <column id="uid_credentials.uid">
	<name>uid</name>
	<name db="oracle">uuid</name>
	<type>string</type>
	<size>&id_len;</size>
	<description>
	  This is the UID (User ID) identifier of the user the credentials are
	  assigned to. Each uid can have multiple credentials assigned. UIDs of
	  subscribers with no credentials assigned do not appear in this table.
	</description>
  </column>

  <index>
	<name>cred_idx</name>
	<colref linkend="uid_credentials.auth_username"/>
	<colref linkend="uid_credentials.did"/>
  </index>

  <index>
	<name>uid</name>
	<name db="oracle">uuid</name>
	<colref linkend="uid_credentials.uid"/>
  </index>

  <index>
	<name>did_idx</name>
	<colref linkend="uid_credentials.did"/>
  </index>

  <index>
	<name>realm_idx</name>
	<colref linkend="uid_credentials.realm"/>
  </index>
</table>