WebSphere brand IBM WebSphere Presence Server, Version 7.0

General considerations for setting up security for Presence Server

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.

The authorization APIs

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.

Increasing the level of user privacy by integrating with IBM WebSphere XML Document Management Server Component

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.

Authentication for SIP requests

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.

Authentication for HTTP requests

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.

White list and black list authorization

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.

Authorizing incoming 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.

Here are the guidelines by which Presence Server authorizes SUBSCRIBE requests:
  • White-list subscribers are always allowed to subscribe to all presentities. This overrides presence authorization rules.
  • Black-list subscribers are never allowed to subscribe. Again, this overrides presence authorization rules.
  • When a subscriber is not specified in either list, presence authorization rules are applied.
Here are the guidelines by which Presence Server authorizes requests to subscribe to watcher information:
  • White-list subscribers are always allowed to subscribe.
  • Only white-list subscribers are allowed to subscribe on group/uri-list for watcher information.
  • Black-list subscribers are never allowed to subscribe.
  • When a subscriber is not specified in either list, Presence Server verifies that the identity of the authenticated subscriber matches the watched identity as indicated in the "To" header of the SIP message. This guarantees that a user who is not on the white list can subscribe only to his or her own watcher information.
Here are the guidelines by which Presence Server authorizes PUBLISH requests:
  • White-list publishers are always allowed to publish and to enable administrator publication on behalf of other users.
  • Black-list publishers are never allowed to publish.
  • When a publisher is not specified in either list, Presence Server verifies that the identity of the authenticated publisher matches the published presentity as indicated in the "To" header of the SIP message. This guarantees that a user who is not on the white list can publish his or her own presence information.
For all PUBLISH requests, Presence Server also verifies that the presence identity appearing in the PIDF document matches the identity indicated in the "To" header. When the identities do not match, the PUBLISH request is rejected–even if the publisher is on the white list.

Handling anonymous users

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.

Message security

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.




Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.