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.

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.