We'll look at four primary SAML use cases: two for web browsers and two that use SOAP. The first, called the pull profile
, shows how SAML can be used to create a single sign-on between two web sites. The pull profile uses SAML artifacts (in essence, tokens) that are passed from one site to another using a URL query string. The site making the assertion (the source site) creates a link to the destination site containing the artifact in the URL, and when the user clicks on it, the destination site receives the artifact as part of the HTTP GET
request. The artifact is a key that the second site can then use to pull the actual assertion from the source site.
The pull profile is illustrated in Figure 11-2. In the example,
Mary visits http://Airline.com and purchases airline tickets. During her interactions with http://Airline.com, she has logged in and has been authenticated.
At the point of purchase, http://Airline.com recommends that Mary rent a car from http://RentalCar.com and provides a link containing an embedded SAML artifact.
When Mary clicks on the link, the artifact is transferred to http://RentalCar.com.
http://RentalCar.com makes a SAML request using the artifact.
http://RentalCar.com receives an authentication assertion in return, allowing Mary to use the services on http://RentalCar.com without signing onto http://RentalCar.com directly.
These examples assume that there is a contractual arrangement between http://Airline.com and http://RentalCar.com, and that Mary has given her consent for http://Airline.com and http://RentalCar.com to federate her identity. We'll discuss those issues more in Chapter 12.
Another way of using SAML with browsers is called the push profile
. Here, the source site creates a web form containing the complete assertion. When the user submits the form, it is sent to the destination site using an HTTP POST
, effectively pushing the assertion from the source site to the destination site using the HTML form mechanism. In this scenario, the source site digitally signs the assertion using XML Signature so that the destination site can be assured of its authenticity.
The push profile is illustrated in Figure 11-3. In this example, the following occurs:
Mary visits http://Airline.com just as she did in the last example.
At some point in the session, http://Airline.com returns an HTML form that contains the complete, digitally signed identity assertion.
Mary submits the form to http://RentalCar.com. http://RentalCar.com checks the digital signature and, being satisfied with the credentials, processes Mary's request.
Suppose Mary decides to rent a car. http://RentalCar.com might need additional information from http://Airline.com. To get that information, http://RentalCar.com can make an attribute request, perhaps asking for Mary's credit card and address information to complete the purchase. Attribute requests and http://Airline.com's responses would be
packaged and sent across the wire in the bodies of SOAP messages, as shown in Figure 11-4. This use case is called a direct request and response. In this example:
http://RentalCar.com makes a request.
http://Airline.com responds.
In the example shown in Figure 11-4, the SAML requests and responses are the payload of the SOAP message, because they are the data of interest. Sometimes, however, SAML is used to authenticate a SOAP message itself. In this case, called the web services profile, the SAML assertion is about the contents of the SOAP body and is contained in the SOAP header. The assertion in the header is a SAML artifact or digitally signed assertion, just as in the pull and push profiles, that pertains to the action being taken in the body. The web services profile is illustrated in Figure 11-5.
The primary benefit of SAML is that the security context for a subject travels with the subject (in the form of the assertion) so that a new context doesn't need to be recreated at each associated site. This reduces the need to store and synchronize identification, authentication, and authorization information at each site. The data is more secure, single sign-on can be implemented, attributed-based authorization can be supported, and multiple service providers can be federated using the same language and protocols.