Security Assertions Markup Language

The SAML specification is part of the Oasis Security Services Technical Committee, but the original ideas for SAML originated from Netegrity. The specification will address interoperability between security providers for multiple areas of security that do not exist today. The main area of concentration is in authentication and authorization across multiple Web sites, to gain single sign-on (SSO) functionality (Figure 15.2).

Figure 15.2: SAML

SAML is based on the principle of assertions. An assertion is a statement regarding the properties of a given user that one party exchanges with another party. In the security context, an assertion becomes the exchange of security properties among security providers. Because each security provider may implement security differently (username/password, certificates, etc.), the assertion states that the user was authenticated at a specific time using a certain type of authentication.

SAML defines a protocol and format for distributing SAML data among trusted third parties in a business relationship. It supports pushing of data assertions from an authoritative source to a receiver and can also support pulling of data assertions from an authoritative source to a receiver. This allows SAML to exchange event notifications between trusted partners in a relationship. SAML also handles different assertion types for decisions and attribute assertions.

The SAML specification provides specifications in the following four categories:

• Assertions and protocols. Defines the semantics and syntax for XML-based SAML assertions, protocol requests, and responses.

• Bindings and profiles. Defines the frameworks for encapsulating and transporting SAML assertion requests and responses.

• Security and privacy. Defines, for implementers of SAML, guidelines to mitigate security risks for threats against a SAML-based implementation. All implementers should read this document.

• Conformance. Defines a mechanism to ensure compatibility and interoperability among the various SAML implementations.

SAML Architecture

All SAML assertions contain the following common elements: assertion ID, issuer and issuance timestamp, subject, advice, and conditions. In SAML, a subject specifies the name and security domain for which an assertion is requested/ issued. The subject can optionally contain additional information for authenticating the subject. The advice element consists of optional additional information the issuing authority wishes to provide to the relying party regarding how the assertion was made and can support proof of assertion claims.

The conditions element specifies that the assertion is valid only when an evaluation of conditions is provided. This can include specifying a validity period, restrictions on whom the assertion is valid for (audience), and target restrictions, including target parties who have received authority to use this assertion. Target restrictions state that if a party decides to consume an assertion for which it is not the intended target, it must throw the assertion away.

Authentication Assertion

Listing 15.7 shows a request that would be sent to an issuing authority.

Listing 15.7: Authentication assertion

 <saml:Request MajorVersion="1" MinorVersion="0"     Request>     <samlp:AuthenticationQuery>         <saml:Subject>             <saml:NameIdentifier SecurityDomain="flutebank.com" Name="rlimbaugh"/>         </saml:Subject>     </saml:AuthenticationQuery> </saml:Request> 

In the above example, a party authorized to issue assertion requests creates a request for a subject whose name is "rlimbaugh" in the security domain "flutebank.com". A SAML response will be generated based on this request. Listing 15.8 shows the response.

Listing 15.8: Authentication assertion response

 <saml:Response MajorVersion=1" MinorVersion="0"    InResponseTo="987.65.432.10.12345678"    StatusCode="Success">    <saml:Assertion MajorVersion="1" MinorVersion="0"       Assertion       Issuer="flutebank.com"       IssueInstant="2001-09-11T09:48:00Z">       <saml:Conditions          NotBefore="2001-09-11T09:48:00Z"          NotAfter="2001-09-11T11:26:00Z"/>       <saml:AuthenticationStatement          AuthenticationMethod="Password"          AuthenticationInstant="2001-09-11T09:48:00Z">          <saml:Subject>             <saml:NameIdentifier                SecurityDomain="flutebank.com" Name="rlimbaugh"/>          </saml:Subject>       </saml:AuthenticationStatement>    </saml:Assertion> </saml:Response> 

Here, the assertion is valid for only the specified time period, according to the saml:Conditions element. saml:AuthenticationStatement states the authentication method used. In our example, subject "rlimbaugh" is a member of the security domain "flutebank.com" and was authenticated using password authentication.

SAML is responsible for making assertions about authentication and authorization but does not provide the mechanism to perform these actions.

Attribute Assertion

An attribute assertion verifies the result of an evaluation of an access control policy, such as whether an end user is authorized to perform a specific transaction at a specified time. The key point to remember is that it is an assertion, not a fact. Listing 15.9 shows an attribute assertion request.

Listing 15.9: Attribute assertion request

 <saml:Request MajorVersion="1" MinorVersion="0"    Request>    <samlp:AttributeQuery>       <saml:Subject>          <saml:NameIdentifier>             SecurityDomain="flutebank.com"             Name="rlimbaugh"/>       </saml:Subject>       ...       <saml:AttributeDesignator          AttributeName="Employee_ID"          AttributeNamespace="flutebank.com"/>    </saml:AttributeQuery> <saml:Request> 

In this example, a request for attribute assertion is sent to the issuing authority (in this case flutebank.com), to assert the value of certain attributes.

Authorization Assertion

An authorization assertion does not state that a user is allowed to perform a certain type of transaction but indicates only that the user is permitted to perform a particular instance of that type of transaction at a given time.

An authorization assertion communicates information about the attributes of a particular subject. One example may be an airline site that wants to determine whether the user is a Gold, Chairman's, or Medallion frequent flyer, to allow a user access to special services. Other examples may be whether the user's account balance is up to date or on the verge of being reported to a credit agency. Listing 15.10 shows an authorization assertion that will check whether a current Flute Bank customer can access an external service.

Listing 15.10: Authorization assertion

 <saml:Request MajorVersion="1" MinorVersion="0"    Request>    <samlp:AuthorizationQuery       Resource="http://www.loans.co.tt/members/accountAccess">       ...       <saml:Subject>          <saml:NameIdentifer             SecurityDomain="flutebank.com"             Name="rlimbaugh"/>       </saml:Subject>       <saml:Actions Namespace="flutebank.com">          <saml:Action>Read</saml:Action>          <saml:Action>Change</saml:Action>       </saml:Actions>       <saml:Evidence>          <saml:Assertion>             ... Assertion Information ...          </saml:Assertion>       </saml:Evidence>    </saml:AuthorizationQuery> </saml:Request> 

In this example, a SAML request for authorization assert is sent to the issuing authority (Flute Bank) to assert whether the subject is allowed to access the specified resource given the specific evidence. Evidence is an assertion on which an issuing party can make authorization decisions. The example demonstrates the request being sent to an issuing authority to assert whether subject "rlimbaugh" can be allowed read and change access to the specified resource. Listing 15.11 shows the response.

Listing 15.11: Authorization assertion response

 <saml:Response ... >    <saml:Assertion ... >       <saml:Conditions ... />       ...       <saml:AuthorizationStatement          Decision="Permit"          Resource="http://www.loans.co.tt/members/accountAccess">          <saml:Subject>             <saml:NameIdentifier                SecurityDomain="flutebank.com"                Name="rlimbaugh"/>          </saml:Subject>       <saml:AuthorizationStatement>    </saml:Assertion> <saml:Response> 

Here, the returned authorization assertion contains saml:Authorization-Statement, which permits the subject "rlimbaugh" access to the specified resource.

Let us look at a scenario in which SAML may be used in a Web service transaction between two organizations. In this example, we will need to pass several types of information securely manner for a SAML-enabled provider to make a decision, as Figure 15.3 shows.

Figure 15.3: SAML assertion

A user is logged into the luxurycarscheap.com Web site and has decided to pay for his dream Porsche Boxster by applying for a loan. He would also like to purchase insurance for his vehicle at the same time. Luxurycarscheap.com has a partnership with a lender named flutebank.com for auto loans. Luxurycarscheap .com also has a partnership with a company called reallycheapinsurance.com, which provides the insurance that luxurycarscheap.com sells via a Web service. Both flutebank.com and reallycheapinsurance.com need information on who is requesting a loan and insurance and some attributes about them. We would also like to interact with our state's motor vehicle division and automatically register the purchased vehicle. Figure 15.4 shows the flow of information that could occur in this scenario.

Figure 15.4: SAML assertion response

Applications that use SAML can also define their own custom assertions.

As you can see from the figures, SAML uses a common XML schema for basic information that includes the assertion ID, date and time of issuance, and the time interval for which the assertion is valid. Assertions may depend on additional information from an asserting party or on other valid assertions.

SAML Bindings and Profiles

SAML can be used over a variety of network/application protocols. A SAML binding specifies how SAML is transported over particular protocols and how request-response messages should be handled. For example, the SAML SOAP binding describes how SAML request-response messages are mapped into SOAP messages. The HTTP binding for SAML specifies how request-response messages are mapped into HTTP messages. To date, the SAML specification has defined only how a SAML request-response is handled using SOAP over HTTP.

Applications can define their own custom protocol for exchanging SAML assertions. A SAML profile describes how an originating party embeds SAML assertions in other object types for transport. For example, the SAML profile for SOAP specifies how SAML assertions are added to SOAP messages as well as how the SOAP headers are affected by SAML assertions.

Some of the products and vendors that have implemented support for SAML include Baltimore SelectAccess, Entegrity, Netegrity Siteminder, Securant, Sun ONE Identity Server, Systinet WASP, and Verisign Trust Services Integration Kit.