BITS & BOLTS
SAML's portable trust makes federated identity work.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The way most e-commerce works--B2B and B2C--is that a person signs on to a Web site and provides his credentials, which are verified through stored identities typically only valid for that session and that domain. It's a cumbersome process that slows the user experience and transactions, and requires expensive identity stores and management systems.
The idea behind Web services and federated identities is that you only need one identity to access multiple accounts and resources across different, trusted domains. The magic behind the process is Security Assertion Markup Language (SAML), the standard that breathes life into the growing world of XML-based communications.
SAML, developed by OASIS in collaboration with several identity management vendors, provides a means for trusted parties to leverage federated identities and for trusted third parties to act as an authority for hundreds or thousands of service providers simultaneously. In theory, this means that one identity can be ported across trusted domains to provide transparent access to data, applications and resources. It's the foundation of Web services and promises to improve user experiences and save enterprises money.
SAML 1.1 and 2.0 (pending approval) provide an XML-based framework for entities to make claims, or "assertions," and flexibly allow entities to exchange attribute, authentication and authorization information. SAML effectively eliminates the spider web of one-to-one trust relationships, which serve as the foundation for most of today's identity-dependent platforms.
How does SAML work? The primary players in a SAML exchange are the subject, the asserting party and the relying party/service provider.
The subject is the user, about which an assertion is made. The asserting party is the subject's home domain, which presents credentials on the subject's behalf to trusted members of a federated network. The relying party/service provider is the receiving member of the SAML assertion; it grants access rights and permissions based on the credentials provided by the asserting authority.
Each SAML assertion has three parts: the authentication (this is Bob), the attribute (Bob is a purchasing agent of a trusted partner) and the authorization decision (Bob can make purchases on behalf of his company).
SAML profiles define how SAML assertions are requested, created and passed. SAML 1.1 has two profiles: The Browser/POST profile delivers a digitally signed assertion directly to the subject to pass to the relying party; and the Browser/Artifact profile issues an assertion artifact, which acts like a time-sensitive token for a relying party to pick up a valid assertion from a trusted asserting party. Assertion artifacts are used when relying parties want to receive assertions only from the trusted party.
These profiles are value independent; they don't specify the information that's passed in an assertion. The SAML specification allows for the development of private profiles for specific uses, giving developers the ability to infinitely extend the uses of SAML assertions.
In the real world, SAML would work something like this: Wholesaler CarMonster (relying party) could fulfill an order from retailer Reliable Parts (subject) on the basis of a SAML authentication assertion brokered by a portal site, Automotive ClearingHouse (asserting party). Since both companies have trust relationships with the portal site, they rely on its valid SAML assertion about the Reliable user's identity, eliminating the need to establish a direct relationship between CarMonster and Reliable Parts.
Reliable's user--Bob--logs in to the Automotive ClearingHouse site, which digitally signs a SAML assertion or returns an assertion artifact. When Bob places his order, his browser sends the SAML assertion (or the assertion artifact) to CarMonster. The assertion might be a simple authentication that Bob is Bob, but could include attribute assertion, such as his credit limit or shipping address.
The same process applies for internal applications and portals. For instance, a company could provide its employees access to their 401(k) information through its portal using SAML assertions.
In addition to passing authentication information when employees log in, the portal could pass attribute information, such status (retired vs. active) and restrict authorization rights to the 401(k) manager based on whether they're still valid employees. The 401(k) manager could make decisions about the employees' application capabilities when they're granted access.
Efficiency Through Federation
Providers of enterprise identity management applications are rapidly supporting the use of SAML assertions as a means of passing identity information from a trusted source, like a company's directory service, to applications of all types. SAML could help application developers make authentication more transparent to users. In addition, the ability to pass attribute assertions to applications could foster enhanced role-based access controls while reducing role management complexity.
What can't be automated are the trusted relationships between domains. These relationships must be established out of band, either party to party or with a trust authority. It's relatively trivial to say, "Trust access assertions from ABC Corp.'s domain," but it's a different matter to first engage in that trust and provide levels of controls to maintain the integrity and security of your domain. Enterprises looking to federate should examine their partners' security programs to ensure they don't invite a compromise through a federated portal.
Likewise, SAML assertions are subject to the same fraud and misuse risks as conventional authentication credentials. Just as a fake driver's license makes it easier to get a counterfeit credit card, so too does a poor initial identification process make it easy to use the SAML standard to create fraudulent federated identities.
Nevertheless, SAML's flexible interoperability and reliance on accepted standards make it an easy choice for authentication, authorization and security attribute assertions. SAML assertions are written in XML and can use XML-supported digital signatures, and encryption algorithms and schema. The SAML request/response protocols rely on SOAP over HTTP for transport. Both Liberty Alliance and Web Services Security specify SAML assertions in their standards.
SAML 2.0 promises to extend its usefulness. Expect these improvements:
- Specifications that will simplify attribute exchanges among federated entities.
- Improved cross-domain account linking for relying party organizations that need to maintain some information about external users.
- XML encryption.
- The capability to embed Kerberos tickets in assertions.
- Enhanced trust through context metadata that can convey information on how a user was identified before his account was created, and the strength of the authentication method used.
Despite the refinements in SAML 2.0, the standard is still a work in progress. Even in its embryonic form, SAML is making strides in how trusted partners share applications, data and services across domains without building and managing identity stores for external users. Under the SAML schema, customers move transparently from site to site without reauthenticating, and organizations can cut identity management costs, reduce the complexity of identity infrastructure and improve the user experience.
Dig Deeper on Web Services Security and SOA Security