E-community process flow

An e-community consists of a master authentication WebSEAL server (MAS) and additional WebSEAL servers located in the home domain and remote domains. The MAS can exist as a single instance of a WebSEAL server, or a set of WebSEAL replicas located behind a load balancer (where the load balancer is identified as the MAS).

All participating local and remote WebSEAL servers need to be configured to use the home domain MAS for initial client authentication. This configuration is a hard requirement for servers in the home domain, and a soft requirement for servers in remote domains. For example, some servers in remote domains can be configured to handle their own authentication. These servers, and the resources they protect, can operate independently of the e-community, even if they are located in a participating e-community domain.

The e-community implementation is based on a vouch-for system. Typically, when a user requests a resource from a WebSEAL server where the user has not established a valid session, WebSEAL prompts the user for authentication information. In an e-community configuration, the WebSEAL server identifies a vouch-for server and requests verification from this vouch-for server the user has authenticated.

The vouch-for server has valid credential information for that user. For the user's first request, the vouch-for server is always the MAS. The MAS continues to serve as the vouch-for server for resources located in the home domain. As the user continues with resource requests across the e-community, an individual server in each remote domain can build its own credential for the user (based on user identity information from the MAS) and assume the role of vouch-for server for resources in its domain.

The verification requested of the vouch-for server takes the form of a vouch-for token. The vouch-for server creates the token and returns it to the requesting WebSEAL server. The user identity information in the token is encrypted. The token contains a lifetime limit.

Upon receipt of the vouch-for token, the requesting server builds credentials and a local session for that user. The user can now access the requested resource based on normal authorization controls. The user benefits from not having to log in again—a goal of the e-community model.

Refer to the following diagram as you follow the e-community process flow in the remainder of this section. The process flow describes two possible FIRST access scenarios (1 and 2). These are followed by two possible NEXT access scenarios (3 and 4) which follow immediately after 2 or 3. Scenario 5 occurs any time after the initial access.

"Vouch-for" Servers

• The MAS is always used to authenticate a user accessing any part of the e-community for the first time.

  The MAS should perform only as an authentication server and not as a resource provider. The MAS should not be configured to act as a master authentication server and, simultaneously, to protect resources. This recommendation addresses performance concerns and is not a security requirement.

• The MAS is always the vouch-for server for the home domain (domain A in this example).
• A domain-specific e-community cookie is used to identify the vouch-for server for all other servers within a given domain. The vouch-for server is the first server in a domain that requests a vouch-for token from the MAS. The vouch-for server provides vouch-for information for the user within the domain. Subsequent requests for vouch-for services in a given remote domain can be made locally by this server, rather than accessing the out-of-domain MAS. In the home domain, the e-community cookie identifies the MAS as the vouch-for server.

(1) FIRST e-Community Local (Domain A) Access: WebSEAL 1

1. User requests a resource protected by WebSEAL 1 (within the same domain as MAS). The browser contains no e-community cookie for this domain. WebSEAL 1 has no cached credentials for the user.

2. WebSEAL 1 configuration has e-community authentication enabled and specifies the location of the MAS. WebSEAL 1 redirects the browser to a special vouch-for URL on the MAS.
3. The MAS receives the vouch-for request and, failing to find credentials for that user, prompts the user to login.
4. After successful login, the MAS builds a credential for the user, stores it in the cache, and redirects the browser back to the originally requested URL on WebSEAL 1 with an encrypted vouch-for token. In addition, a domain A-specific e-community cookie is placed on the browser to identify the vouch-for server for this domain (in this case, the MAS).
5. The token create module can obtain extended user attribute information that can be used by the destination server during the user mapping process.

   Attribute information can come from two sources. First, the [ecsso-token-attributes] stanza of the WebSEAL configuration file is checked for configured stanza entries. Secondly, the CDMF library is called (cdmf_get_usr_attributes) to obtain additional attributes. Attributes from the CDMF library override any settings in the [ecsso-token-attributes] stanza.

6. If the login attempt is unsuccessful, the MAS returns a vouch-for token that indicates a failure status. This token is constructed to be indistinguishable from a success status vouch-for token. The requesting server reacts to a failure status token as if the user had failed local authentication.

7. WebSEAL 1 decrypts the token. Identity mapping should not be required within the same domain. If identity mapping is required, WebSEAL 1 can use the cross-domain mapping framework (CDMF).

8. If an attribute list for the new identity is constructed, the token consume module first processes the attributes according to the settings in the [ecsso-incoming-attributes] stanza of the WebSEAL configuration file. Then the module calls to the CDMF library, which performs the actual user mapping (cdmf_map_usr).
9. The CDMF library passes the user's mapped identity, and any extended attribute information, back to the token consume module. The token consume module passes the identity to the WebSEAL server, which builds a credential.
10. The authorization service permits or denies the request based on the user's credential and the specific ACL and POP permissions associated with the requested resource.

(2) FIRST e-Community Remote (Domain B) Access: WebSEAL 3

1. User requests a resource protected by WebSEAL 3 (remote domain B). The browser contains no e-community cookie for this domain. WebSEAL 3 has no cached credentials for the user.

2. WebSEAL 3 configuration has e-community authentication enabled and specifies the location of the MAS. WebSEAL 3 redirects the browser to a special vouch-for URL on the MAS.
3. The MAS receives the vouch-for request and, failing to find credentials for that user, prompts the user to login.
4. After successful login, the MAS builds a credential for the user, stores it in the cache, and redirects the browser back to the originally requested URL on WebSEAL 3 with an encrypted vouch-for token. In addition, a domain A-specific e-community cookie is placed on the browser to identify the vouch-for server for this domain (in this case, the MAS).
5. The token create module can obtain extended user attribute information that can be used by the destination server during the user mapping process.

   Attribute information can come from two sources. First, the [ecsso-token-attributes] stanza of the WebSEAL configuration file is checked for configured stanza entries. Secondly, the CDMF library is called (cdmf_get_usr_attributes) to obtain additional attributes. Attributes from the CDMF library override any settings in the [ecsso-token-attributes] stanza.

6. If the login attempt is unsuccessful, the MAS returns a vouch-for token that indicates a failure status. This token is constructed to be indistinguishable from a success status vouch-for token. If the user fails authentication at the MAS, then the user is prompted for a local authentication at WebSEAL 3. If the user's account exists on this server, authentication then succeeds.

7. WebSEAL 3 decrypts the token.

8. If an attribute list for the new identity is constructed, the token consume module first processes the attributes according to the settings in the [ecsso-incoming-attributes] stanza of the WebSEAL configuration file. Then the module calls to the CDMF library, which performs the actual user mapping (cdmf_map_usr).
9. The CDMF library passes the user's mapped identity, and any extended attribute information, back to the token consume module. The token consume module passes the identity to the WebSEAL server, which builds a credential for the user.

10. WebSEAL 3 creates and sets a second e-community cookie (valid for domain B) on the browser, identifying WebSEAL 3 as the vouch-for server for domain B.
11. The authorization service permits or denies the request.

(3) NEXT e-Community Local (Domain A) Access: WebSEAL 2

1. User requests a resource protected by WebSEAL 2 (within the same domain as MAS). The browser contains a domain A e-community cookie identifying the MAS as the vouch-for server. WebSEAL 2 receives this cookie. WebSEAL 2 has no cached credentials for the user.

2. WebSEAL 2 configuration has e-community authentication enabled and specifies the location of the MAS. The presence of the domain A e-community cookie overrides the WebSEAL 2 configuration for the MAS location. The cookie provides WebSEAL 2 with the identity of the vouch-for server. (If scenario 2 occurred first, there would also be a domain B cookie maintained on the browser that would not be sent to a domain A server.)

3. WebSEAL 2 redirects the browser to a special vouch-for URL on the domain A vouch-for server identified in the cookie (in this case the MAS, because WebSEAL 2 is in domain A).
4. The MAS receives the vouch-for request and finds credentials for that user in the cache (this occurred in scenario 1 and 2).
5. The MAS redirects the browser back to the originally requested URL on WebSEAL 2 with an encrypted vouch-for token. (See scenario 1 and 2 for a description of extended attribute handling.)

6. WebSEAL 2 decrypts the token and builds its own credential for the user.
7. The authorization service permits or denies the request.

(4) NEXT e-Community Remote (Domain B) Access: WebSEAL 4

1. User requests a resource protected by WebSEAL 4 (remote domain B). If scenario 2 occurred first, the browser contains a domain B e-community cookie identifying WebSEAL 3 as the vouch-for server. WebSEAL 4 has no cached credentials for the user.

2. WebSEAL 4 configuration has e-community authentication enabled and specifies the location of the MAS. The presence of a domain B e-community cookie overrides the WebSEAL 4 configuration for the MAS location. The cookie provides WebSEAL 4 with the identity of the vouch-for server. (If scenario 1 occurred first, there would only be a domain A cookie maintained on the browser that would not be sent to a domain B server. The configured MAS location would be used instead. WebSEAL 4 would then become the vouch-for server for domain B.)

3. If scenario 2 occurred first, WebSEAL 4 redirects the browser to a special vouch-for URL on the domain B vouch-for server identified in the domain B cookie (in this case WebSEAL 3).

4. WebSEAL 3 receives the vouch-for request and finds credentials for that user in the cache (this occurred in scenario 2).

5. WebSEAL 3 redirects the browser back to the originally requested URL on WebSEAL 4 with an encrypted vouch-for token. (See scenario 1 and 2 for a description of extended attribute handling.)

6. WebSEAL 4 decrypts the token and builds its own credential for the user.
7. The authorization service permits or denies the request.

(5) ANOTHER e-Community Local (Domain A) Access: WebSEAL 2

1. User connects to WebSEAL 2 (domain A) with a request. If scenario 3 occurred, WebSEAL 2 has cached credentials for the user.
2. The authorization service permits or denies the request.

Logout from the e-Community

• If the user logs out by closing the browser, all SSL sessions and all e-community cookies are cleared.

• If the user logs out using the /pkmslogout page, the SSL session and e-community cookie for that domain are cleared.

Parent topic: E-community single signon concepts