|
@@ -0,0 +1,271 @@
|
|
|
+<?xml version="1.0" encoding="UTF-8"?>
|
|
|
+<!DOCTYPE table PUBLIC "-//iptel.org//DTD DBSchema V1.0//EN"
|
|
|
+ "http://iptel.org/dbschema/dtd/1.0/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>
|