Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

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

WebSEAL’s 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