This article can also be found in the Premium Editorial Download "Information Security magazine: How security pros can benefit from information sharing."

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

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

    Requires Free Membership to View

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.

This was first published in January 2005

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: