Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This project involved the implementation of presence based privacy policies and filtering presence information based on these policies. This results in generating different presence documents for different watchers that have subscribed to presence information of a presentity according to the presentity's privacy preferences for each watcher.
The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity, in order to learn their presence information. This subscription is handled by a presence agent. However, presence information is sensitive, and a presence agent needs authorization from the presentity prior to handing out presence information. The presence authorization document format is specified by the presence authorization specification [2] which is an extension of a common policy document specification [1]. An authorization policy is a set of rules. Each rule contains conditions, actions, and transformations. The conditions specify under what conditions the rule is to be applied to presence server processing. The actions element tells the server what actions to take. The transformations element indicates how the presence data is to be manipulated before being presented to that watcher, and as such, defines a privacy filtering operation. A presence authorization document can be manipulated by clients using several means. One such mechanism is the XML Configuration Access Protocol (XCAP) [5].
The rest of this document provides a more detailed description with respect to background, architecture and implementation of presence authorization and privacy filtering.
Background
Privacy policies specifies 2 types of authorizations :
1. Subscription Authorization and Handling
2. Privacy Filtering of presence information.
Subscription Authorization and Handling
When a SUBSCRIBE request comes from a watcher to subscribe to presence information of a particular presentity, the watcher must be authorized to view any presence information. This authorization is done as follows:
a) Select all rules that match for the given watcher based on watcher identity, sphere and day and time.
b) If there are multiple rules that match, obtain the maximum value of subscription authorization from all these matched rules.
Subscription authorization is specified in a rule by the <sub-handling> element in the presence authorization document. This element takes the values of block(0), confirm (1), polite-block(2) and allow(3) with default value as block. The final subscription authorization value is returned to the subscription handler that handles the subscription appropriately. If there is no rule matching a particular watcher or if there is no such presentity in the database appropriate information is returned to the subscription handler.
Privacy Filtering of presence information
Once a watcher is authorized to view the presence information of a presentity, further filtering needs to be done as to which elements of presence information needs to be shown or not to be shown to each watcher. This process is done as follows:
a) Select all rules that match for the given watcher based on watcher identity, sphere and day and time.
b) If there are multiple rules that match, obtain the final values of each permission by the rule combination process specified in the common policy document[1].Most of the permissions are of boolean type(true/false) with default being false.A false value indicates removal of the corresponding element from the presence document while a true value indicates allowance of the corresponding element in the presence document to be presence.
c) When the composed presence document is passed on to the filtering module, each of these permissions is applied to this presence document. This results in a final filtered per-watcher document which is then published to the watcher.
The description above briefly outlines the presence authorization process that takes place in the presence server.
The various components involved in the presence authorization and filtering process are as follows :
1. MYSQL Rules Database
2. Privacy Query module
3. Policy Document - Database module
4. Privacy Rule Match module
5. Subscription Authorization module
6. Privacy Filter module
A diagrammatic representation of how these components fall in place in the presence server is shown below :
a. At the server startup, the rules of policy documents of all existing presentities are transferred to the database.
b. When a SUBSCRIBE request comes in to the presence server, the subscription handler requests for subscription authorization from the SubscriptionAuthorization module. The policy server looks up the rules database with the watcher identity, filters out rule ids of rules that hold good for that watcher based on watcher identity, sphere and validity period of the rule. If there are multiple rules that match then the maximum value of subscription-handling value is taken from these rules and returned to the subscription handler which then appropriately handles the subscription.
c. When a NOTIFY/PUBLISH request comes in from the notify/publish handler with a composed presence document, privacy filtering needs to be applied to this document. This is done by looking up the database again for rules that match the watcher identity and presentity whose document is being published and further selecting rules based on rule validity period and sphere of the presentity. Matching rules are combined according to the rule combining algorithm specified in the common policy specification [1]. The results of the rule combination process gives the final values of permissions that are to be applied for that watcher.
d. Once the final permissions are obtained, the composed presence document is parsed and during parsing it checks if the current element that it is parsing is to be retained or not. If itis to be removed, this element and its children are removed from the presence document DOM. Once this parsing is done, this final filtered document gets published to that watcher.Thus different watchers of a presentity gets different views of a single presence document.
Program Documentation
The various components and modules are :
1. Rules Database :
This database stores all the rules from policy documents of different presentities. The schema of the various tables in the database are as shown below:
a. ruleidentity :
This table contains columns pertaining to the <identity> condition of the rule.This table would be used for filtering rules based on watcher identity.
| Field | Type | Null | Key | Default | Extra |
| presentity | varchar(255) | ||||
| ruleid | varchar(255) | ||||
| one_id | varchar(255) | YES | NULL | ||
| scheme | varchar(255) | YES | NULL | ||
| except_id | varchar(255) | YES | NULL | ||
| except_scheme | varchar(255) | YES | NULL | ||
| except_domain | varchar(255) | YES | NULL | ||
| many_domain | varchar(255) | YES | NULL |
b. ruleset :
This table contains columns for conditions such as sphere and validitiy period of the rule as well as values of all other permissions (transformations). It also contains the subscription-handling parameter of the rule which would be used for subscription authorization.
| Field | Type | Null | Key | Default | Extra |
| presentity | varchar(255) | PRI | |||
| ruleid | varchar(255) | PRI | |||
| sphere | varchar(255) | YES | NULL | ||
| validity_from | datetime | YES | NULL | ||
| validity_to | datetime | YES | NULL | ||
| subhandling | enum('block','confirm','polite-block','allow') | block | |||
| provide_all_services | tinyint(1) | 0 | |||
| provide_all_devices | tinyint(1) | 0 | |||
| provide_all_persons | tinyint(1) | 0 | |||
| provide_activities | tinyint(1) | 0 | |||
| provide_class | tinyint(1) | 0 | |||
| provide_device_id | tinyint(1) | 0 | |||
| provide_mood | tinyint(1) | 0 | |||
| provide_place_type | tinyint(1) | 0 | |||
| provide_place_is | tinyint(1) | 0 | |||
| provide_privacy | tinyint(1) | 0 | |||
| provide_relationship | tinyint(1) | 0 | |||
| provide_status_icon | tinyint(1) | 0 | |||
| provide_sphere | tinyint(1) | 0 | |||
| provide_time_offset | tinyint(1) | 0 | |||
| provide_user_input | enum('false','bare','thresholds','full') | false | |||
| provide_note | tinyint(1) | 0 | |||
| provide_unknown_attribute | tinyint(1) | 0 | |||
| unknown_attribute_name | varchar(255) | YES | NULL |
c. servicepermission
This table is used for obtaining service related permissions.
| Field | Type | Null | Key | Default | Extra |
| presentity | varchar(255) | ||||
| ruleid | varchar(255) | ||||
| service_type | varchar(255) | ||||
| service_value | varchar(255) |
d. devicepermission
This table is used for device related permissions.
| Field | Type | Null | Key | Default | Extra |
| presentity | varchar(255) | ||||
| ruleid | varchar(255) | ||||
| device_type | varchar(255) | ||||
| device_value | varchar(255) |
e. personpermission
This table is used for person related permissions.
| Field | Type | Null | Key | Default | Extra |
| presentity | varchar(255) | ||||
| ruleid | varchar(255) | ||||
| person_type | varchar(255) | ||||
| person_value | varchar(255) |
2. Policy Query module :
This is a module which is a sort of a central repository of all MYSQL queries that are required to be executed in the privacy filtering and subscription authorization process. This module obtains the database connection instance from the database manager and executes MYSQL queries with this connection instance.
3. Policy Document - Database module
This is a module that parses a XML presence policy document for a presentity and transforms it to one or more rules into the database.
4. Privacy Rule Match module :
This module implements the rule matching process for a given watcher. The rules are matched based on watcher identity, sphere and current day and time. As a result of rule matching, a list of rule-ids is obtained. If the rule-id list contains more than one rule-id then the corresponding rules are combined to a single rule by using the rule combination algorithm specified in [1].A filter object is created for the watcher which stores the final permissions for that watcher.
5. Subscription Authorization module :
This module implements an API for retrieving the final subscription handling for a given presentity, watcher and sphere.It makes use of Policy Query and Privacy Rule Match modules to the final subscription handling and returns this value to the subscription handler.
6. Privacy Filter module :
This module takes as input the DOM of composed presence document for a given presentity, identity of the watcher. It then obtains the filter for this watcher from Privacy Rule Match module and filters the DOM of the presence document based on the values of elements in the filter. The filtered DOM is returned to the publish handler which then publishes the final presence document.
Additional Program Documentation
There is definitely scope for future work in this project.
1. Intelligent filtering can be implemented ,that is, a mechanism wherein the filters for different watchers can be stored and if a new request for filtering comes in, the program would check if it has already done the same filtering for someother watcher.If so, it can just publish that filtered document without having to actually parse the presence document again.
2. Performance measurements need to be done for filtering process in the presence server and accordingly alternative mechanisms of filtering could be devised.
Acknowledgements
I would like to thank Professor Henning Schzulrinne, Dept. of Computer Science, Columbia University for providing valuable guidance and feedback throughout this project. I would also like to thank Vishal.K.Singh ,Columbia University, for all his help in getting more acquainted with the SIP presence server and providing guidance throughout this project.
References
3 H.Sugano, S.Fujimoto, G.Klyne, A.Bateman, W.Carr, J.Peterson, Presence Information Data Format (PIDF), RFC 3863, August 2004.
4 H. Schulzrinne, V.Gurbani, P.Kyzivat, J.Rosenberg, RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) , draft-ietf-simple-rpid-09, September 2005
5 J.Rosenberg , The Extensible Markup Language(XML) Configuration Access Protocol (XCAP) , draft-ietf-simple-xcap-08, October 2005.