The CDSSO Challenge

Conventional SSO works via HTTP cookies within a single DNS domain. In such situations, Access Manager and agent-protected resources reside in the same DNS domain. When a user successfully authenticates to Access Manager, an HTTP session cookie (also known as an SSO token) will be set to the user's browser, with Access Manager's DNS domain as the cookie domain. From this point on until the session terminates or expires, the browser will always present the SSO token to any server in the same DNS domain (for example Access Manager agents), based on the HTTP protocol. This allows Access Manager and the policy agents to reexamine the validity of the user session and identity, and then enforce security policies without re-authentication.

The SSO solution breaks down when the Access Manager and agents reside in different DNS domains. For example, Access Manager and some agents may reside in www.primary.com while some other agents reside in www.partner.com. During authentication to Access Manager, the SSO token (HTTP cookie) will still be set to the browser with .primary.com as the cookie domain. However, when the browser accesses agent-protected resources in www.partner.com, it will not present the SSO token to the servers, as dictated by the HTTP protocol. To the Access Manager agents, no SSO token means the user is not authenticated. The agents will force the user to authenticate, which will then fall into a loop, since the Access Manager in the right DNS domain will see the browser does have a valid session SSO token. The Access Manager will redirect the browser back to the original requested resource in www.partner.com, thus leads to a non-stopping loop.