CDSSO process flow with attribute transfer and user mapping

The following process flow description is illustrated in Figure 1.

  1. Any user who wants to participate in multiple domains must have a valid user account in the initial domain and an identity that can be mapped into a valid account in each of the participating remote domains.

    A user cannot invoke the CDSSO functionality without initially authenticating to an initial secure domain (A) that contains the user's account.

  2. The user makes a request to access a resource in domain B using a custom link on a Web page located on the server websealA.

    The link is constructed using a special CDSSO management page expression:

      /pkmscdsso?destination-URL

    For example:

      http://websealA/pkmscdsso?https://websealB/resource.html

    The pkmscdsso management page is a management command to the WebSEAL server. It is not represented in the object space and we cannot attach policies to it.

  3. The request is first processed by the websealA server in domain A. The websealA server calls the ssocreate module to build an authentication token containing the user's credentials, including the ISAM identity (short name), the current domain ("A"), additional user information, and a time stamp.

  4. The token create module can obtain extended user attribute information that can be used by domain B during the user mapping process.

    Attribute information can come from two sources. First, the [cdsso-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 [cdcsso-token-attributes] stanza.

  5. WebSEAL triple-DES encrypts this token data with the symmetric key generated by the LMI. This key file is shared and specified in the [cdsso-peers] stanza of the WebSEAL configuration file on both domain A and domain B WebSEAL servers.

  6. The token contains a configurable time stamp (authtoken-lifetime) that defines the lifetime of the token. The time stamp, when properly configured, can prevent replay attacks.

  7. The token is placed in a redirected request to the destination server, using the URL contained in the pkmscdsso link. For example: 
    http://websealB/resource.html?PD-ID=encoded-authn-token&PD-REFERER=websealA

    The PD-ID argument name in the query string is obtained from the cdsso-argument stanza entry of the WebSEAL configuration file.

    The ssocreate module provides the PD-REFERER argument with the name of the origin server (websealA) so the destination server (websealB) accurately knows where the redirected request is from, without relying on the browser's Referer header information.

  8. The websealA server sends a redirect response for the resource on websealB containing the encrypted token back to the browser.

  9. The websealB server recognizes the request as one containing a CDSSO token (based on the value of the cdsso-argument stanza entry of its WebSEAL configuration file).

  10. The websealB server decodes and validates the token as coming from the referring domain. This process is performed by the "token consume" authentication module (ssoconsume).

  11. When constructing the attribute list for the new identity, the token consume module first processes the attributes according to the settings in the [cdsso-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).

    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.

  12. The websealB authorization service permits or denies access to protected objects based on the user's credential and the specific ACL and POP permissions associated with the requested objects.