Single Sign-On Explained


This article can also be found in the Premium Editorial Download "Information Security magazine: Special manager's guide: Monitoring identities."

Download it now to read this article plus other related content.


    Requires Free Membership to View

SSO emerging solutions

Federated SSO is a solution in response to the real-world problem of users accessing Web applications across security domains. The development of federation products was initially driven by the Web access management (WAM) vendors. The current market also includes stand-alone federation products and others, including SSL VPNs, virtual directories, fine-grained authorization and XML/Web services security.

Common applications for federation include the following:

  • Web SSO to benefits Web sites: Employees at a large corporation can authenticate once when accessing the employee portal and get access to external benefits Web sites (for example, retirement investment accounts).
  • Intra-organization Web SSO: Due to subsidiary acquisitions and political issues within large corporations, heterogeneous Web applications are distributed across multiple security domains, but users can get Web SSO to these applications.
  • B2C partnerships: Some businesses with common customers can provide "one-stop shopping" with a single authentication and personalized environment.
In the case of the travel industry (airline, hotel and car rental Web sites), the user's destination city and airport, as well as their length of stay, can be shared between the businesses to provide a seamless shopping experience.

Most federation deployments use security assertion markup language (SAML) to facilitate Web SSO. SAML assertions are XML-based documents that are typically digitally signed by the identity provider, who is responsible for the initial user authentication.

When the user arrives at the service provider's site, the service provider retrieves the user's SAML assertion, validates the identity and authentication status and enables access to the local resources without reauthentication.

Federation technologies have coalesced around the SAML 2.0 specification, which unifies the SAML 1.x standard, the Liberty Alliance Identity Federation Framework (ID-FF) specification, and others. SAML 2.0 is not backward compatible with the SAML 1.x specification, which many federation early adopters are currently using. A number of federation deployments leverage Liberty Alliance's ID FF1.2 to support user global logout.

To add to the mix, Microsoft released Active Directory Federation Services (ADFS) as part of Windows Server 2003 R2 in early 2006. ADFS does not utilize SAML 2.0, but instead uses WS-Federation. Within the enterprise, ADFS can also be utilized to facilitate cross-forest trust in a firewall-friendly manner. ADFS includes support for a SAML 1.1-based token, but not the SAML protocol.

Interoperability between WS-Federation and SAML-based environments is provided within some federation products. Many federation products can also bridge the gap between the other standards available in the marketplace and provide interoperability between WS-Federation, SAML 1.x, Liberty and SAML 2.0 federation systems.

While federation technologies do a good job of providing Web SSO, some challenges remain.

First, the negotiation of the legal federation agreements between organizations can be complicated due to liability and trust issues. Some of the difficulty with business agreements can be attributed to the industry's lack of experience with this process. But over time, these agreements will become easier. Moreover, the increase in industry marketplaces that leverage federation will help provide all implementers with more real-world examples.

While federation can facilitate user authentication, most service provider Web applications require the creation or mapping of a known user account.

Lastly, PKI permeates federation, as it is the default mechanism to establish technical trust between the identity provider and the service provider. Compared to other PKI models, federation has a simpler approach since digital certificates are not issued to users. Rather, certificates are issued to the federation components, like the identity provider and, potentially, the service provider. Organiza-tions must pay close attention to the certificates' expiration date, or risk interrupting user access to Web resources. Other challenges with PKI exist (for example, secure key storage and trust hierarchies)

--Mark Diodati

Web Access Management
[how it works]

Web access management (WAM) systems provide SSO across heterogeneous Web applications and are a staple in most large enterprises. Unlike eSSO systems, WAM systems typically do not replay usernames and passwords into Web applications; they go beyond eSSO by providing authorization controls to Web resources. WAM systems do not have clients, per se, since access to resources is via the Web browser.

In most cases, the user authenticates once when accessing a resource protected by the WAM system. The WAM issues the browser a cryptographically protected cookie, which maintains authentication state across Web applications protected by the WAM system. The two principal benefits of WAM systems are Web single sign-on and externalization of Web application security. Security externalization typically results in simpler policy maintenance, since authorization and authentication are not maintained within every Web application. Security externalization can also result in improved compliance, as the organization has a holistic view of Web application security for those applications under WAM control.

WAM Policy Management
Unlike eSSO systems, WAM systems can usually enforce authorization to applications. The richer policy model comes with a price--the organization generally spends more time creating a WAM policy than an eSSO policy.

When discussing Web access management policies, it's not uncommon to hear the words "roles" and "rules." Organizations can use a combination of roles and rules to build their WAM authorization policies. The use of LDAP groups to determine access is an example of role-based authorization. Rules are used to both provide fine-grained authorization as compared to role-based access, and to limit role proliferation. With rules, an attribute, which is frequently attached to the user object in LDAP, is used in conjunction with regular expressions to determine access. One example of rule-based authorization is, "If the user's accounts payable signing limit is greater than $50,000, the user can approve the payment."

The WAM system can use both roles and rules concurrently to determine access rights. The use of rule-based authorization should be used with great care, as excessive use can complicate the debugging of authorization policy and potentially slow down the performance of the WAM system.

This was first published in August 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: