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.
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:
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)
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