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.
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.
Figure 4-11 e-community single sign-on model
The e-community mechanism involves the following steps:
1. A user makes a request for a protected resource controlled by a WebSEAL server in one of the e-community domains. This WebSEAL does not yet have an established secure session with this user.
2. The WebSEAL server redirects the user to the MAS and sends with the request a special directive (pkmsvouchfor), which requests that the MAS provide identity information for the user.
3. The MAS checks to see whether the user has already been authenticated to the e-community, and if not, the MAS authenticates the user.
4. The MAS sends a token back to the original WebSEAL server that contains credential information that vouches for the user’s identity.
5. The WebSEAL server maps the identity provided to it by the MAS to an appropriate Access Manager within its local domain and establishes a secure session with the browser.
WebSEAL MAS mas.domainA.com
WebSEAL 1 ws1.domainA.com
WebSEAL 2 ws2.domainA.com
WebSEAL 3 ws3.domainB.com
WebSEAL 4 ws4.domainB.com
DOMAIN A DOMAIN B
Client
Home Domain
Domain A User Registry
Domain B User Registry
Figure 4-12 summarizes the flow of an initial e-community user authentication.
Figure 4-12 e-community initial identity determination process
Within the home domain, unauthenticated requests are always vouched for via the MAS. In other participating domains, after the user initially logs in to the MAS, subsequent authentication activities to other WebSEAL servers in those domains are handled locally. The first WebSEAL in the domain that validates the user’s identity against the MAS then vouchesfor that user’s identity within the local domain. This is depicted in Figure 4-13 on page 173.
Secure
https://www.xyz.com/abc.html
2. WebSEAL redirects user to MAS WebSEAL with request for "voucher".
3. Browser forwards voucher request to MAS.
4. If a session has not yet been established, the user is authenticated and mapped to a Home Domain identity (4a).
5. A voucher token is created (in a cookie), and the MAS redirects the user back to the original WebSEAL.
6. The browser forwards the request and voucher cookie to the original WebSEAL, which maps the user to an appropriate Domain A identity (6a), establishes a secure session, and processes the request.
Once the session is established with the Domain A WebSEAL, subsequent requests are processed normally without need for vouchering/authentication.
Figure 4-13 e-community subsequent identity determination process
The key advantage of e-community single sign-on over CDSSO is that the initial URL request can be made directly to the target WebSEAL server. Recall that with CDSSO, the URL request must go through the WebSEAL to which the user is currently authenticated. In an e-community configuration, the target WebSEAL is specifically configured to retrieve credential information through the vouching mechanism, and the URL request itself need not be accompanied by special processing or contain special characteristics, as in the CDSSO case.
User synchronization and e-community single sign-on
The default mapping for e-community single sign-on is to map a user from the home domain exactly as it appears into another domain. For example, if a user Secure
Domain A
Browser
WebSEAL 1
(User has authenticated to an e-community MAS in a previous request to WebSEAL 2. WebSEAL 2 now will vouch for subsequent identity "voucher" requests by other WebSEALs for this user in this domain.)
1. User requests URL from WebSEAL 1:
https://www.xyz.com/abc.html
2. WebSEAL 1 redirects user to WebSEAL 2 with request for "voucher".
3. Browser forwards voucher request to WebSEAL 2.
4. WebSEAL 2 provides a voucher cookie token, and redirects the user back to WebSEAL 1.
5. The browser forwards the request and voucher cookie to WebSEAL 1, which maps the user to the correct Domain A identity, establishes a secure session, and processes the request.
Once the session is established with the WebSEAL 1, subsequent requests are processed normally without need for vouchering/authentication.
1
2 5
Domain A User Registry
WebSEAL 2
4 3
New session is established here
Identity is vouched for here, where user already has an active
session.
authenticates as user123 to the home domain and is returned to domain B, the user must also exist as user123 in domain B even though they were never prompted to authenticate in 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 (CDMF) 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 e-community single sign-on
Virtual hosts are also allowed to participate in an e-community single sign-on environment. The same concepts apply to a virtual host WebSEAL environment that apply to physical WebSEALs themselves.
For example, let’s take the following virtual host junctions:
www.abc.com:80
www.abc.com:443
www.xyz.com:80
www.123.com:80
There are three domains that would be participating in e-community single sign-on in this environment:
abc.com
xyz.com
123.com
We could make the www.abc.com server the MAS server. That means whenever authentication would need to occur for www.xyz.com, www.abc.com, or
www.123.com, all requests would first be forwarded to www.abc.com for authentication and e-community token creation.
Note: www.abc.com:80 and www.abc.com:443 are a virtual host junction protocol pair. They correspond to the same server and same objectspace in Access Manager.