Refer to these general considerations to achieve the most efficient and secure use of Presence Server. It is assumed that WebSphere® Application Server Network Deployment application security is enabled when you run Presence Server.
Presence Server provides APIs with which you can develop customized authorization policies. Developers can use the authorization APIs to write pluggable applications that provide authorization information. This can be an effective way to increase the level of user privacy control for users.
An external authorization program registers with the APIs to manage authorization on a specific event package. The authorization APIs are used only when presence authorization rules are disabled and when white lists and black lists are also disabled.
For more information about the authorization APIs, refer to the topic Extending Presence Server authorization.
For more information about developing presence authorization rules, refer to IETF RFC 4745 and RFC 5025.
You can also increase the level of user privacy control for users by integrating with IBM® XDMS.
Presence Server uses the XML XCAP and SIP as the communication mechanisms with a group list server, such as IBM XDMS, for SIP SUBSCRIBE and NOTIFY messages. IBM XDMS is used for storing group lists (resource lists), for retrieving authorization lists (black and white lists), and for getting presence rules documents.
For details, see the topic Configuring for integration with IBM XDMS.
Presence Server uses the Trust Association Interceptor (TAI) security component, included with the WebSphere IMS™ Connector product, to handle authentication for incoming SIP requests.
Presence Server depends on the Call Session Control function (CSCF) to check the user's authentication and eligibility for the service before the request reaches Presence Server. Trust Association Interceptor takes the user identity from the p-asserted-identity header that is added to the request by the CSCF and creates a WebSphere Application Server principal.
To authorize incoming SIP requests, the TAI inserts the WebSphere Application Server principal value into every request. Presence Server uses the asserted identity header on each incoming request, and it uses this identity for all user and request authorization. Presence Server can be configured to use the previous identity in case the p-asserted-identity header is omitted in subsequent requests.
For more information about how Presence Server uses TAI security, refer to the topic Planning authentication security using the Trust Association Interceptor.
The authentication mechanisms in Presence Server are designed to support content indirection, in which a SIP message can contain an indirect reference to desired content. See the topic Content indirection for more information.
Presence Server does not perform authentication for incoming HTTP requests. Instead, when a request reaches Presence Server, it is assumed that the request has already been authenticated by another component. It is further assumed that an authenticated identity exists in the WebSphere Application Server principal object. This is the identity that Presence Server uses for authorization.
In a typical deployment, an IMS proxy component authenticates the sender of the request and adds an X-3GPP-Asserted-Identity header. The IMS HTTP interceptor then extracts this header and translates it to a WebSphere Application Server principal, similar to the way in which the P-Asserted-Identity header is handled for SIP. Because Presence Server relies solely on the WebSphere Application Server principal, there is no dependency on the Trust Association Interceptor.
A non-IMS or WebSphere-only deployment is also supported for HTTP requests. In such a deployment, another authentication method, such as base WebSphere authentication, can be used.
As is the case with SIP requests, unauthenticated requests may be accepted if they are allowed by the presence rules and if they are not specifically blocked in the server configuration.
Presence Server uses two lists of identities (URIs) for authorization. Identities in the white list are always authorized. Identities in the black list are never authorized. The lists are stored by the IBM XDMS component as documents in the format specified by the mime type application/resource-lists+xml in IETF RFC 4826 (XML formats for representing resource lists).
On startup, Presence Server retrieves the white and black lists from IBM XDMS by means of an XCAP GET operation. Presence Server also subscribes to changes in the lists. When changes occur they affect new, incoming SIP requests, but they are not applied retroactively to existing SIP dialogs. Presence Server will apply the new authorization list for each user on all new and subsequent requests.
Presence Server applies certain guidelines when determining whether to authorize incoming SUBSCRIBE and PUBLISH requests. Presentities (users) can define presence authorization rules to control who can access their presence information and what parts of the information are exposed. (For more information, refer to the topic Presence authorization rules.)
The following guidelines apply to both SIP requests and HTTP requests.
Presence Server treats anonymous users as special identities. To block anonymous access, it is recommended that you put the Anonymous identity in the black list. You can specify presence authorization rules for anonymous users. As a result, presence authorization rules are evaluated when a subscriber is found to be anonymous.
Presence Server supports the Transport Layer Security (TLS) protocol for SIP messages, as defined in IETF RFC 3261. RFC 3261 requires the URI scheme for SIP over TLS to use the sips: prefix; for example, sips:johndoe@example.com. Using TLS preserves the confidentiality and integrity of messaging, provides authentication and privacy of the participants in a session, and prevents denial-of-service attacks.
Presence Server adds a p-asserted-identity when it works with external registrars and with the IBM XDMS. The header, which describes the identity of the Presence Server application, is added to the first SUBSCRIBE request to each external registrar, to the IBM XDMS, and to each SIP external server.