SAML 2.0 is a norm for federated identity, defined by the OASIS consortium.
The functional context where SAML comes in, involves at least two entities (humans or systems) which exchange authentication and authorization data. The first one is named the "asserting party"; this is the entity that makes a claim about something being true. The second one is named the "relying party"; this is the entity that uses the assertion being made. The entity about which an assertion is being made is named the subject (or the principal).
To help anchor these ideas, keep in mind the following basic situation: the "relying party" is a service whose access is protected and which uses the information delivered by an authentication mechanism, the "asserting party", to grant access to a user. The user who wishes to access the service and whose identity is being checked is the "subject".
It is not hard to see that, for this responsibility scheme to work properly, it is necessary to establish a trust relation between both roles. More precisely, the "relying party" should have no doubt that it is dealing with the "true" asserting party and not with an impostor. We'll see shortly how this trust relationship can be ensured within the Shibboleth implementation (see the following section, devoted to this tool).
In the most general setting, the SAML norm defines use cases where several roles collaborate to accomplish a task that implies exchanging authentication and authorization information. But the only use case we shall be interested in in this book, is the Multiple-Domain web Single Sign-on (MDSSO or simply SSO). Before going further, however, let's define a few terms that belong to the SAML vocabulary:
- Authentication delegation. This refers to using an external system (to the application or to the organization) for authenticating a user.
- Federation of identity. This refers to establishing two-way associations among various ID definitions that are specific to some applications, some organizations or, more generally, to some security contexts. It implies delegating authentication to just one of the security contexts. The ID and the associated parameters should then be propagated securely between the contexts with the agreement of the user.
The following figure illustrates the concept of federated identity in the context of a trip reservation on the portal of an airline company. The portal accesses the IS of a car rental company and the IS of a hotel reservation agency. The three applications each take, in turn, the roles of the IdP and the SP during the reservation process. It is expected that each security context generally uses different "user/password" pairs. It is up to the user to enter these credentials when he or she first uses one of the services. The keys, or nicknames, are generated automatically and make federated identity a reality. Subsequently, John Smith will only authenticate with the airline company.
An illustration of a federated identity among three security contexts: that of an airline company, that of a car rental agency, and that of a hotel reservation center. The federation is achieved using keys known only to those contexts that use them. No correlation between the activities of John Smith on the different websites can be demonstrated.
- A SAML assertion. This is the basic building block of SAML. It is a claim about a subject, which an asserting party claims to be true. The detailed structure and the legitimate content of such an assertion are defined in a formal way using an XML schema, namely the SAML assertion XML schema. In principle, these assertions are created by an asserting party on request from a relying party.
- A SAML protocol. This is a set of requests and assertions that are involved in identity management. Again, the set of allowable protocols is defined in an XML schema, namely the SAML protocol XML schema.
- A SAML binding. This specifies how protocol messages are sent over low-level communication layers such as
HTTPorSOAP. - Lastly, a SAML profile, as we already saw, refers to a use case that has been formalized within the SAML norm. The following figure summarizes the relation between these concepts:
Let's now address MDSSO. The two relevant entities are the IdP, the identity provider and the SP, the service provider that were already mentioned above. We distinguish the following two variants, the second of which is actually the one used by Google Apps.
To describe this use case, let's consider, once more, the example of an online trip reservation. A user visits the portal of an airline company, airline.company.com, where he or she logs in. Here, the company plays the IdP role. Assume that during the reservation process the user is redirected, within the portal, to a car rental company, cars.company.com, the latter playing the SP role in this case. In this context, it is up to the IdP, airline.company.com, to initiate the redirection, which explains the name for this use case. Two sub-cases should be distinguished:
- If the user has already made a car reservation with the car rental company in the past, through the same airline portal, then identity federation already occurred and the user won't be asked to authenticate again.
- If however, this is a first visit to the car rental agency through the portal of the airline company, the user will be required to enter his or her credentials for cars.company.com. The SSO system will then establish the appropriate binding with the ID defined on airline.company.com.
In both cases, the SP cars.company.com trusts the IdP airline.company.com to correctly check the identity of the customer.
The SAML 2.0 norm also defines an optional Discovery Service (DS) that allows a user to look for an IdP. We'll come back to this point shortly, when we cover Shibboleth.
A simple example of this use case is when an employee wants to access Gmail, which is protected by a local authentication mechanism. Gmail thus takes the SP role and the local ID directory, that of the IdP. Here, the SP role initiates the external authentication request, hence the name of the use case.
The following section, devoted to authentication delegation, will describe in detail how such an authentication mechanism can be set up. Note that the SSO wording is slightly misleading here, since delegation of authentication does not necessarily imply setting up a SSO in the strictest sense of the term.
It is however entirely possible to integrate Google Apps in an enterprise SSO.
To avoid any possible confusion, let us emphasize that, once the identity of a user has been checked within a Google Apps domain, he or she will have access to any of the Google Apps services. This set of services should be considered, from the point of view of SSO, as just a single web application and not as a set of applications that benefit from identity federation.
Sh ibboleth is an open-source reference implementation of federated identity principles as they are defined in the SAML 2.0 norm. The software is developed under the auspices of the Internet2 consortium and is distributed under the Apache 2.0 license. Shibboleth implements the three primary elements from the SAML 2.0 norm, namely the following:
- The Service Provider (SP). This is the software layer that protects the access to an existing service. It is in charge of sending authentication requests to the IdP and consumes the SAML assertion it sends back. On a LAMP platform, the SP includes a Linux daemon and an Apache module. On a WIMP platform, it includes a Windows service and an ISAPI filter.
- The Identify Provider (IdP). This is the software layer that handles the authentication requests by delegating them to an existing system. It produces answers that will be used by the SPs. These answers contain all the data defining the ID of the user as well as associated parameters and authorizations. The Shibboleth implementation is a web app that can run in the Tomcat container, for instance.
- The Discovery Service (DS). This allows the user to choose an IdP from a list. The Shibboleth implementation comes with a web application that provides this feature.
Shibboleth 1.3 does not itself provide an authentication mechanism. Thus, an external authentication mechanism will be needed. One possibility is to use the authentication services of the Java container in which the IdP runs; Tomcat is just one such example.
The following figure succinctly describes a web-SSO authentication process (actually, it is really a delegation of authentication) which involves the three entities implemented by Shibboleth, namely the SP, the IdP, and the DS:
- The user tries to access a protected resource. If the user recently accessed another resource that is protected by the same Shibboleth SP, he or she will be able to access it immediately, without further ado. If, however, this is a first attempt or if this is the first time that he or she is using this particular SP, then the user's browser will be redirected to the Discovery Service.
- The Discovery Service presents a list of IdPs, usually institutions or organizations where the user is already referenced and that are likely to check his or her identity. The user chooses one of these IdPs and will then be redirected to the corresponding login page. This step can be bypassed when the browser remembers a previous choice from the same user. This step is not mandatory in the web SSO profile but SAML 2.0 makes it possible.
- The user is shown the login page he or she is familiar with and enters his or her credentials, which are then transmitted to the SP.
- The SP checks that the user who was just authenticated has the appropriate rights to access the requested resource. If that is the case, access is granted. The SP can also use the parameters that were transmitted, together with the authentication data, to define an authorization level, for instance.
The IdP sends the SP a certificate that proves that the it (the IdP) really is who it claims to be. The SP can thus trust the SAML assertions made by the IdP. In the case of Google, it is the ACS (Assertion Consumer Service) that performs the check of the certificate (see the following section devoted to authentication delegation).
The authentication process with Shibboleth: 1. A user attempts to access a protected resource. The user's browser is redirected to the Discovery Service (DS). 2. The DS asks the user to choose an IdP where he or she is referenced. 3. The IdP generates a login window. 4. If the user was granted the appropriate rights, he or she accesses the requested resource. The IdP sends a certificate to the SP in order for the latter to check the legitimacy of the SAML assertions made by the former.