Introduction

The Cross Domain Single Sign-On (CDSSO) is a mechanism by which a Single Sign On (SSO) solution can be extended to Sun Java Enterprise System Access Manager protected resources in different DNS domains. CDSSO makes it possible for users to authenticate once against Access Manager in a primary DNS domain, and then access protected resources in other DNS domains.

CDSSO is a Sun proprietary mechanism from Access Manager, designed before Security Assertion Markup Language (SAML) and the Liberty Alliance Project existed. CDSSO is still available today in Access Manager and it is easier to set up and manage than SAML and Liberty in certain cases.

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.

CDSSO versus SAML/Liberty

CDSSO has nothing to do with SAML/Liberty even though its implementation uses Liberty-like protocol exchange AuthNResponse. SAML/Liberty solves a broader set of SSO issues where CDSSO focuses on a much narrower subset.

CDSSO requires all Access Manager policy agents to be configured to use a single Access Manager server. This means only one user identity can exist in the entire system. In SAML/Liberty, user identities can exist in multiple systems such as Service Providers (SPs) and Identity Providers (IDPs). SAML/Liberty enables account mapping from IDP to SP. Account mapping from IDP to SP is not possible with CDSSO. Because of the single user store assumption, issues such as account mapping, attribute flow and session synchronization in SAML/Liberty are not relevant to CDSSO. If the situation fits the following, then CDSSO may be a simpler and more suitable solution than SAML/Liberty:

1. Only Sun Java System Access Manager and Sun policy agents are involved.

2. Access Manager policy agents are all configured to use the same Access Manager infrastructure where multiple Access Manager instances can exist.

3. Access Manager uses a single user identity store.

4. Multiple Access Manager instances configured for high-availability must all reside in a single DNS domain. Only policy gents can reside in different DNS domains.