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

Chapter 4. Configuration and customization 169

domain B. This presents the challenge of synchronizing the user accounts that

need to participate in single sign-on between domains

If a custom written cross-domain mapping framework is used, then it is possible

to map a user from one domain to a different user in another domain. However, if

a one-to-one mapping is used, the problem of synchronizing users still would

exist regardless of whether or not the IDs matched from one domain to another.

Virtual hosts and CDSSO

Cross-domain single sign-on is not supported with virtual hosts and virtual host

junctions. If single sign-on is needed between separate DNS domains and/or

Access Manager domains, and either virtual hosts or virtual host junctions are

used, e-community single sign-on is the only technology supported for this type

of functionality.

4.10.3 e-community single sign-on

e-community single sign-on supports a cross-domain authentication capability.

However, it differs from CDSSO in a few key respects. Recall that in CDSSO,

authenticated identities are

forwarded. In an e-community scenario, identities

are instead retrieved—it is a

pull model. The use of e-communities has certain

advantages over CDSSO, yet it also has architectural impacts that are not

encountered in a CDSSO environment.

Instead of having to use special URLs to indicate the use of single sign-on as in

the CDSSO model, e-community allows for direct access to secured links. This

has a benefit over CDSSO in that users can bookmark links to resources but will

still be allowed to participate in e-community.

In this model, multiple Access Manager domains are defined to be part of a

single e-community. While each participating domain has its own user registry,

one of the domains is designated to be the

home domain. Users requesting

protected resources in any of the participating domains initially authenticate to a

Master Authentication Server (MAS) in the home domain. After the initial

authentication has taken place, the user has an e-community identity based on

the home domain’s user registry. A user’s e-community identity subsequently

can be mapped, as required, to local identities by WebSEAL servers in other

domains within the e-community.

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

The e-community model is shown in Figure 4-11 on page 171. Some key points

to be aware of in the e-community model are:

򐂰 The model supports access using direct URLs (bookmarks) to resources.

This feature contrasts with the CDSSO model that relies on a specially

configured pkmscdsso link.

򐂰 All users who are participating in the e-community authenticate against a

single master authentication server (MAS) located in the home domain.

򐂰 The e-community implementation allows for “local” authentication in remote

domains if the user does not have a valid account with the MAS (for example,

users who belong to domain B but do not participate in the domain A-domain

B e-community).

򐂰 A user who fails authentication with the MAS when requesting a resource in a

non-MAS (but participating) domain is given the option to authenticate to the

local server where the request is being made.

򐂰 The MAS (and eventually other selected servers in the remote domains)

“vouches for” the user’s authenticated identity.

򐂰 Domain-specific cookies are used to identify the server that can provide

“vouch for” services. Domain cookies allow servers in a remote domain to

request “vouch for” information locally. The encrypted contents of

e-community cookies do not contain user identity or security information.

򐂰 Special tokens are used to pass encrypted “vouched for” user identity. The

“vouch for” token does not contain actual user authentication information.

Integrity is provided by a shared secret key (triple-DES) generated by the

cdsso_key_gen utility. The token contains a timeout (lifetime) value to limit

the duration of the token validity.

Single sign-on with e-community can be used if there are two completely

separate Access Manager security environments (two different Policy Servers

and user registries) or in an Access Manager multi-domain environment where

there is one Policy Server and one user registry shared between domains (this

does not imply that the users and groups are shared between domains, though).

Note: Users who do not exist in the MAS home domain can still authenticate

to their own domain and access protected resources. This allows a company

to restrict who can essentially single sign-on to resources. Only users defined

to both the MAS domain and the domain where the protected resource is

defined can participate in e-community single sign-on.