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.

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.

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.

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.

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.

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.

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.

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.

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.

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.