Sun OpenSSO Enterprise 8.0 Technical Overview

Which Flavor of SAML to Use?

When choosing the flavor of SAML to use there are a number of things that should be taken into account. For example, SAML v1.x and SAML v2 assertions and protocol messages are incompatible. The following section have more information to help make the decision.

Using SAML v2 or OpenSSO Enterprise CDSSO

Cross Domain Single Sign On (CDSSO) is a proprietary mechanism from Sun OpenSSO Enterprise, designed before any federation specifications existed. The basic difference between the proprietary CDSSO (as described in Part II, Access Control Using OpenSSO Enterprise) and SAML v2 is that CDSSO uses a single authentication authority, a mechanism to move a cookie between multiple DNS domains. SAML v2, on the other hand, gives you the option of using multiple authentication authorities, with one authority asserting the identity of the user to the other.

CDSSO, in certain cases, is easier to set up and manage than federation but, federation solves a broader set of single sign-on issues than CDSSO. CDSSO requires all policy agents to be configured to use a single OpenSSO Enterprise server. This means only one user identity can exist in the entire system whereas, when using SAML v2, user identities can exist on multiple systems (service providers or identity providers). Because of the single identity in CDSSO interactions, issues such as account mapping, attribute flow and session synchronization are not relevant thus, if you need to implement these features, use SAML v2. If the following points are valid to your planned deployment, CDSSO may be a simpler and more suitable solution than federation.

For more information on CDSSO, see Chapter 6, Models of the User Session and Single Sign-On Processes.

Using SAML v1.x or Liberty ID-FF

The Liberty ID-FF (as described in Using the Liberty ID-FF) and SAML v1.x should only be used when integrating with a partner that is not able to use SAML v2. SAML v1.x was designed to address the issue of cross-domain single sign-on. It does not solve issues such as privacy, single logout, and federation termination. The Liberty Alliance Project was formed to develop technical specifications that would solve business process issues including single sign-on, account linking and consent, among others.

The SAML v1.x specifications and the Liberty Alliance Project specifications do not compete with one another. They are complementary. In fact, the Liberty Alliance Project specifications leverage profiles from the SAML specifications. The decision of whether to use SAML v1.x or the Liberty specifications depends on your goal. In general, SAML v1.x should suffice for single sign-on basics. The Liberty Alliance Project specifications can be used for more sophisticated functions and capabilities, such as global sign-out, attribute sharing, web services. The following table compares the benefits of the two.

Table 11–1 Comparison of the SAML v1.x and Liberty Alliance Project Specifications

SAML v1.x Uses 

Liberty Alliance Project Uses 

Cross-domain single sign-on 

Single sign-on only after user federation

No user federation 

User federation 

No privacy control, best for use within one company 

Built on top of SAML 

User identifier is sent in plain text 

User identifier is sent as a unique handle 

Single log out 

Single log out