Automated identity systems need a way of creating and distributing authentication and authorization assertions . Kerberos, for example, is one system that does this. Recently, SAML, or the Security Assertion Markup Language, has gained considerable traction as a security credential standard. In addition to standardizing ways to use XML to represent security credentials, SAML defines a protocol for requesting and receiving credential data from a SAML authority service. We'll see in Chapter 12 that SAML is used as part of several other standards for creating federated identity systems.
In practice, SAML usage is straightforward. A client makes a request about a subject to a SAML authority, and the authority returns assertions about the identity of the subject for a particular security domain. For example, the subject might be a person identified by his email address in a DNS domain (e.g., john@windley.com). There are several common SAML usage patterns that we'll explore later in this section.
A SAML authority is an online service that responds to SAML requests. SAML responses are called assertions. SAML authorities come in three types: authentication authorities, attribute authorities, and policy decision points (PDPs). These three types of authorities return three distinct types of assertions:
When a SAML authentication authority receives a request about a particular subject's credentials, the result is returned as a SAML authentication assertion. An authentication authority assets that subject S was authenticated by means M at time T. For example, "Subject Alice in company http://windley.com was authenticated using a password at time 2003-05-06T13:20:00-05:00."
Once an authentication assertion is returned, a SAML attribute authority can be asked for the attributes associated with the subject. These are returned as a SAML attribute assertion. An attribute authority asserts that subject S is associated with attributes A, B, etc. with values X, Y, etc. For example, "Subject Bob is associated with attribute Department with value Engineering and attribute Email with value bob@engr.windley.com."
A PDP returns a SAML authorization assertion in response to a request about a subject's permissions with respect to certain resources. A PDP asserts that subject S has (or has not) been granted permissions for action A on resource R given evidence E. For example, "Subject http://A.com/services/foo is granted permission to read the file at http://B.com/bar as evidenced by assertions A1, A2, and A8."
In practice, a single authority can produce all three types of assertions, or authorities may produce a subset. Authorities can be both producers of assertions as well as consumers of assertions from other authorities.
Assertions contain the following common elements:
Issuer ID and issuance timestamp
A globally unique assertion ID
Subject, including a name and security domain and optionally the subject's authentication data
Optional, additional information provided by the issuing authority; this is called advice
Conditions under which the assertion is valid such as the assertion validity period (e.g., NotBefore
and NotOnOrAfter
)
Audience restrictions
Target restrictions such as the intended URLs for the assertion
Application-specific conditions
The following example shows a SAML attribute request:
<samlp:Request ...> <samlp:AttributeQuery> <saml:Subject> <saml:NameIdentifier SecurityDomain="A.com" Name="cn=Bob"/> </saml:Subject> <saml:AttributeDesignator AttributeName="Department" AttributeNamespace="A.com"/> </samlp:AttributeQuery> </samlp:Request>
This request asks the attribute authority which department
Bob@A.com
is associated with.
The following XML is an example of a SAML authentication assertion:
<samlp:Response MajorVersion="1" MinorVersion="0" RequestID="128.14.234.20.90123456" InResponseTo="123.45.678.90.12345678" StatusCode="Success"> <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="123.45.678.90.12345678" Issuer="Example Company, Inc." IssueInstant="2003-01-14T10:00:23Z"> <saml:Conditions NotBefore="2003-01-14T10:00:30Z" NotAfter="2003-01-14T10:15:00Z" /> <saml:AuthenticationStatement AuthenticationMethod="Password" AuthenticationInstant="2003-01-14T10:00:20Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="A.com" Name="cn=Alice" /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>
In this example response, the authentication authority is asserting that
Alice@A.com
was authenticated on January 14, 2003 at 10:00:23 using a password, and that this authentication is valid between 10:00:30 and 10:15:00 on the same day.
As you can see, SAML requests and responses do not define a wire-level protocol, but are rather carried on some other form of transport, such as HTTP, from the client to the SAML authority. There are any number of possibilities about how SAML might be used. The following section explores four likely scenarios.