Chapter 4. Configuration and customization 167
4.10.2 Cross-domain single sign-on
WebSEAL supports the ability to forward an authenticated identity from a user in
one secure domain to a WebSEAL server in another secure domain. The
receiving WebSEAL then maps the identity provided by the sending WebSEAL to
an identity that is valid in its secure domain. This functionality can also be viewed
as a
push model with respect to authentication.
This functionality is known as cross-domain single sign-sn (CDSSO). In CDSSO,
the user makes a request to a special link on a WebSEAL server, which then
initiates the process to forward the request, along with credential information, to
a WebSEAL server in a different Access Manager domain. If the user were to
instead directly access the link in the target domain, he would have to
authenticate to that domain.
The CDSSO process includes the following steps:
1. A user initially logs on to a WebSEAL server in one secure domain.
2. At some point the user accesses a link controlled by the user’s WebSEAL,
which contains a special directive (pkmscdsso). This directive results in
redirecting the user to a URL controlled by a WebSEAL server in another
secure domain and passing encrypted credential information to the new
WebSEAL.
3. The user is redirected to the other WebSEAL and this server decrypts the
credential information passed to it, maps the identity to one defined in its own
user registry, and then creates a secure session with the browser.
4. At this point the user has established secure sessions with two WebSEAL
servers in different domains, but has only had to log in once.
The tokens are encrypted using triple-DES. The symmetric key is generated by
the cdsso_key_gen utility and exchanged between all WebSEALS that
participate in CDSSO.
Another way of looking at CDSSO is that it provides a mechanism by which a
WebSEAL server in one secure domain can send something analogous to a
letter of introduction to a WebSEAL server in another secure domain.
Note: Cross-domain single sign-on requires that the back-end application is
aware of this functionality existing. It is required to generate the appropriate
URL when forwarding the request to another domain. If back end changes to
an application are not permitted or desired, or if application awareness of
WebSEALs single sign-on functionality is not possible, then e-community
single sign on should be used. See 4.10.3, “e-community single sign-on” on
page 169 for more information.
168 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
Figure 4-10 summarizes a typical CDSSO flow.
Figure 4-10 CDSSO identity determination process
Another significant CDSSO implication for a given secure domain, in addition to
the need to potentially modify back-end applications, involves the mapping of
user identities. How this mapping is done is not really an architectural issue; it is
more a detailed design and implementation concern. The important thing to
remember is that the mapping must make sense for the specific situation.
It is possible (using the CDMF interfaces discussed in 4.10.1, “Cross-domain
mapping framework” on page 166) to map from an ID in one domain to a different
ID in another. However, if the IDs in both domains are the same, a direct mapping
may be done. This is the default and does not require the use of any special
programming interfaces.
User synchronization and CDSSO
The default mapping for CDSSO is to map a user from one domain exactly as it
appears into another domain. For example, if a user authenticates as user123
from
domain A and is forwarded to domain B, the user must also exist as
user123 in domain B even though they were never prompted to authenticate in
Secure
Domain A
Domain B
WebSEAL
Browser
Domain A
WebSEAL
1. User authenticates to Domain A WebSEAL.
2. At some point, user makes a request to a "pkmscdsso" link, which contains a Domain B URL.
3. The Domain A WebSEAL constructs an identity token, and redirects the browser to the Domain B
WebSEAL along with the token.
4. The Domain B WebSEAL receives the identity token, maps the user to a Domain B identity (4a),
and establishes a secure session with the browser.
5. The Domain B URL is processed and the result sent to the browser .
Once the identity is established with the Domain B WebSEAL, subsequent requests are processed
normally without need for authentication.
1
2
3
4
5
Secure
Domain B
Domain A
User Registry
Domain B
User Registry
4a1a

Get Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.