Using public identity mapping, Presence Server can tie together presence information from disparate sources that relate to the same person or presentity but use different, non-correlated identifiers. With identity mapping, presence information from different IDs for the same user are presented as a single aggregated presence document. When a subscriber subscribes to any one of these identities, the subscriber receives the aggregated document.
Presence Server begins by preloading the contents of white and black lists into memory. If public identity mapping is enabled for the white or black lists, Presence Server maps each identity to its fundamental identity and then manages it in memory. For incoming PUBLISH and SUBSCRIBE requests, the publisher/subscriber identity is mapped and the fundamental identity is compared to the identities in the white or black list. When the lists are updated (by default once an hour) the identities are mapped again.
For PUBLISH operations, Presence Server verifies that the publisher is publishing his or her own presence document (unless the publisher in the white list). The identity comparison is based on the UIDNormalizer method for comparison identities without referring to their fundamental identity. The comparison is applied for the sender identity as taken from the WebSphere® Application Server principal (from the p-asserted-identity header) for the "To" header and for the entity attribute as specified in the presence document.
For SUBSCRIBE operations, if presence rules are disabled and the subscriber is not in the white or black lists, Presence Server verifies that the subscriber is allowed by comparing the sender presentity from the WebSphere Application Serverprincipal (as taken from the p-asserted-identity header) with the presentity in the To header, without regard to fundamental identity, and allows the subscription.
When presence rules are enabled, by default Presence Server does not use identity mapping for testing identity conditions. Presence Server tests identity conditions matching using original subscriber identity by applying the UIDNormalizer method for comparison without regards to the fundamental identity. The domain comparison is done using UIDNormalizer as well. The domain of the original subscriber public identity is used for testing the domain condition. A configurable option is provided to apply identity mapping when testing identity conditions. With this option, Presence Server considers fundamental subscriber identity when using UIDNormalizer for testing identity conditions. The domain of the subscriber fundamental identity is used for testing the domain condition in this case.
For a winfo subscription, if the subscriber is not in the white or black list, Presence Server verifies that the subscriber is allowed by comparing the sender presentity from the WebSphere Application Server principal (as taken from the p-asserted-identity header) with the presentity in the To header, without regard to fundamental identity. A watcher that subscribes on any of its public identities receives the document with aggregated watchers for all presentities relating to the same fundamental identity.
The Telecom Application Enablement Feature provides samples. For more information, refer to the IBM WebSphere Telecom Application Enablement Feature information center.