The Liberty Alliance
The pieces of our identity are increasingly scattered across those companies and institutions with which we interact online. Banks, credit card companies, brokerage firms, the department of motor vehicles, insurance companies, government agencies, telephone companies -- the list is growing. Pieces of our identity are doled out across the many computer systems and networks used by our employers, ISPs, bulletin boards, instant messaging systems, and online businesses, all with little coordination, interaction, or control on our part.
Creating a federated identity infrastructure is the key to correcting this situation. For the consumer or employee, federated identity will mean a far more satisfactory online experience, as well as new levels of personalization, security, and control over identity information. The existence of such an infrastructure will open up new business opportunities, including providing economies of scale that lower business costs and expedite the growth of the Internet and ecommerce. Making this happen is what the Liberty Alliance Project is all about.
It should come as no surprise that an infrastructure defined for federated identity on the Internet will leverage the data format of the Internet, that is, XML. Liberty leverages the flexibility and firewall-friendly nature of XML significantly. This paper addresses the specific uses of XML within the Liberty Alliance specifications. Before doing so, we'll set the context in the next section by providing a brief introduction to the Liberty Alliance and explain its goals for defining a framework for federated identity.
What is the Liberty Alliance?
The vision of the Liberty Alliance Project is to enable a networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information. To accomplish its vision, the Liberty Alliance will establish an open standard for federated network identity through open technical specifications that will:
- Support a broad range of identity-based products and services
- Enable commercial and non-commercial organizations to realize new revenue and cost saving opportunities that economically leverage their relationships with customers, business partners, and employees
- Provide consumers with choice of identity provider(s), the ability to link accounts through account federation, and the convenience of simplified sign-on, when using any network of connected services and devices
- Increase ease-of-use for consumers to help stimulate ecommerce
Network identity refers to the global set of attributes that are contained in an individual's various accounts with different service providers. These attributes include information such as name, phone numbers, social security numbers, addresses, credit records, and payment information. For individuals, network identity is the sum of their financial, medical, and personal data, all of which must be carefully protected. For businesses, network identity represents their ability to know their customers and constituents and reach them in ways that bring value to both parties.
The problem with the current state of network identity is that the burden of maintaining these islands of identity falls on the individual. It is the individual that is responsible for remembering the multiple user name/password pairs for each of these identity islands, and it is the individual that must manage the information that each web site maintains in order to ensure that it is both up to date and appropriate. To address the task of remembering all their user names & passwords, users will typically either try to use the same combination (which isn't always possible) or record these values elsewhere.
In either case the result is a reduction in the level of security that the user names and passwords were designed to provide. For many users, the display of a "registration page" -- on which a site asks the user for the information the site deems necessary and relevant to a transaction at hand -- is sufficient to cause the user to click away. Most users are tired of filling in forms; they've done so too many times in the past.
Federated identity will address these issues, removing from Web users some of the burden of maintaining their identity on the Web, allowing businesses interacting with these users to offer new holistic experiences. Understanding and creating the best technical infrastructure to enable these relationships to work in a digital world is the goal of the over 160 member companies within the Liberty Alliance.
How is Liberty Phase 1 using XML?
The Liberty Phase 1 specifications (released in July 2002, updated in January 2003 and available at the Liberty site at http://www.projectliberty.org) make extensive use of XML. The following sections illustrate the different applications of XML within the Liberty specifications.
SAML
SAML (Security Assertions Markup Language) is an OASIS (Organization for Advancement Structured Information Sciences) standard designed to provide a way to define user authentication, entitlements and attribute information in XML documents. Companies need a standard open framework that will enable them to build trust chains across company boundaries, heterogeneous platforms, and multiple vendor solutions.
SAML was designed to leverage the extensibility that XML enables. The Liberty Phase 1.1 specifications leveraged this flexibility, using SAML as a foundation on which to build Simplified Sign-On and Identity Federation.
Simplified Sign-On
Liberty chose to use SAML as the means by which a Principal's authentication status can be communicated between sites. The first site (in Liberty parlance, the "Identity Provider") creates a SAML Authentication Assertion which, as its name suggests, is an assertion the Identity Provider makes as to an authentication event performed by the Principal to the IdP. The SAML assertion is communicated to another site (the "Service Provider") which, based on the trust the Service Provider has for the issuing Identity Provider, will log the Principal into the Service Provider Web site as if the user had actually authenticated directly. The communication of SAML assertions between Identity Provider and Service Provider consequently enables Simplified Sign-On for the Principal. SSO is based on a single authentication to one site which allows a user to access the services of other sites without necessarily being forced to sign-in again.
The following is an example of a SAML Authentication Assertion that the Identity Provider would create and communicate to the Service Provider (some details are omitted for clarity):
<?xml version="1.0"?>
<saml:Assertion Issuer="http://IdentityProvider.com"
IssueInstant="2002-12-17T09:30:47-05:00">
<saml:Conditions NotOnOrAfter="2002-12-17T09:35:47-05:00">
<saml:AudienceRestrictionCondition>
<saml:Audience>http://ServiceProvider.com</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AuthenticationStatement
AuthenticationInstant="2002-12-17T09:30:47-05:00" >
<saml:Subject xsi:type="SubjectType">
<saml:NameIdentifier>342ad3d8</saml:NameIdentifier>
<lib:IDPProvidedNameIdentifier>342ad3d8</lib:IDPProvidedNameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>An Identity Provider, named "IdentityProvider.com", is asserting to a Service Provider, named "ServiceProvider.com", that the Principal known to both of them as '342ad3d8' authenticated to IdentityProvider.com at approximately 9.30 in the morning on December 17/2002. When ServiceProvider.com receives this assertion, it will grant access to the appropriate account (that of the Principal it refers to externally as '342ad3d8') to the individual "presenting" the assertion.
The IDPProvidedNameIdentifier element in the separate
Liberty namespace above demonstrates how Liberty extends the base SAML
Authentication Assertion. By building on SAML in this manner (rather than
defining a new syntax) Liberty was both able to deliver its Phase 1.1
specs in a relatively short time-frame (approximately 6 months) as well as
take advantage of the broad support for SAML within the
marketplace. Consequently, we are already seeing early implementations of
the Liberty Phase 1 specification -- vendors able to leverage the support
for SAML that is appearing in products (many of those companies active in
the SAML initiative are also active members of Liberty).
The following diagram illustrates one scenario by which a Liberty Identity Provider and Service Provider can communicate a SAML Authentication Assertion in order to enable SSO for a Principal. In this model, rather than the Identity Provider sending the actual SAML Authentication assertion to the Service Provider, the Identity Provider initially sends only an artifact that acts as a pointer to the SAML assertion; this pointer is then dereferenced by direct communication between the Service provider and the Identity Provider.
|
| Process Flow for SSO |
Pages: 1, 2 |
