Based on a situation where the user needs to authenticate to a server which we shall call as authentication server, after which the user wants to access an application on a different server, say server-A, this problem can be classified into two sub-categories:

1) User authentication – This part of identity management deals with the aspects of identifying a user. In other words, here we answer who is who. Traditionally, this is done by using user id and password, but several other user authentication schemes can be used, such as hardware tokens, digital certificates, and increasingly these days, biometrics.

2) Distributing authentication and authorization information – In this part of the puzzle, we need to be able to share information about the user (i.e. the fact that the user has successfully authenticated) along with the details of what the user can do (i.e. authorization) to any other interested party. For example, we may want to inform server-A that the user has successfully authenticated to the authentication server, and therefore, should be allowed to access server-A, provided she has the necessary access rights. We need to keep in mind that this exchange of information between the authentication server and server-A must happen in a secure fashion. Otherwise, it can lead to chaos.

We describe the process below.

1. User provides necessary credentials (user id-password, or something similar) to the authentication server.
2. The user is interested in accessing server-A.
3. Server-A sends a request to the authentication server to confirm that the user has been successfully authenticate.
4. To this request, the authentication server sends a confirmation response.
5. User can now access server-A.

Something similar is provided by the Kerberos protocol. It is quite popular as well. Both Windows and UNIX families of operating systems have wide support for Kerberos.

In the last few years, this has further led to the development of an XML-based protocol for helping devise identity management solutions. Welcome to Security Assertion Markup Language (SAML).

How does SAML work?

SAML is quite straightforward to understand. A client (in our example, server-A) sends a request about a subject (in our example, the user) to a SAML authority (in our example, the authentication server). The authority returns SAML responses called as assertions regarding the identity of the subject pertaining to a particular security domain.

Let us take a practical situation to understand this.

1.Ram visits www.railway.com and purchases train tickets. For this purpose, he had to of course authenticate himself to the site. The site verified his credentials and considered Ram to be a valid user.
2.After the tickets are purchased, Ram sees a screen on the same site for booking a taxi (with the URL www.taxi.com) from the destination station to a hill station, which he also wants to visit. Also, www.railway.com provides a URL containing an embedded SAML package.
3.Ram clicks on that URL. The SAML package that was with Ram in the earlier step is now sent to www.taxi.com.
4.Using this package, www.taxi.com prepares a SAML request and sends it to www.railway.com.
5.When www.railway.com receives this SAML request, it verifies the necessary credentials, and sends an authentication assertion back to www.taxi.com. This allows Ram to use the services of www.taxi.com without having to separately authenticate/log in (creating the effect of Single Sign On or SSO).

This is shown below:

.

This is called as the browser pull profile model. In the browser push profile model, in step 2, www.railway.com provides an HTML form along with a digitally signed identity assertion. When Ram fills and submits the form, the request is sent to www.taxi.com along with the signed identity assertion, proving to www.taxi.com that Ram is an authenticated user. In this case, therefore, www.taxi.com does not have to go to www.railway.com, as it already trusts Ram based on the assertion received above.

Classification of assertions

We have stated earlier that SAML responses are called as assertions.

SAML authorities themselves can be classified into three types: Authentication authorities, Attribute authorities, and Policy Decision Points. They can respectively provide three types of assertions: SAML authentication assertion, SAML attribute assertion, and SAML authorization assertion. This is depicted below.

Of course, one authority can perform the role of all the three authorities, or can deal with only a sub set. Similarly, an authority can be both consumer as well as producer of assertions.
Let us discuss the types of assertions as depicted in the diagram.

Assertion details
An assertion typically contains the following information.

• Id of the issuer
• Timestamp when the issuance was made
• Information about the subject
• Additional information, if any (optional), called as advice
• Validity period
• Restrictions, if any
• Any other criteria or conditions

Assertion examples
Rather than discussing all possibilities (a total of request and response types), we shall just depict one request example and one response example. Similar concepts would apply to the other types.Here is an example of an SAML authentication assertion. Here, the railway company is confirming that user Ram has been authenticated successfully along with the information as to till when the authentication information is valid.

<samlp:Response MajorVersion=”1” MinorVersion=”0”
RequestID=”128.10.12.23.987654” InResponseTo=”122.81.89.23.2234690”
StatusCode=”Success”>

     <saml:Assertion MajorVersion=”1” MinorVersion=”0”
       AssertionID=”122.81.89.23.2234690” Issuer=”railway company”
       IssueInstant=”2008-03-12T11:06:00Z”>

          <saml:Conditions
          NotBefore=”2008-03-12T11:06:00Z”
          NotAfter=”2008-03-12T11:36:00Z” />

     <saml:AuthenticationStatement
     AuthenticationMethod=”Password”
     AuthenticationInstant=”2008-03-12T11:05:50Z”>

  <saml:Subject>
  <saml:NameIdentifier
      SecurityDomain=”test.com”
           Name=”cn=Ram” />
       </saml:Subject>
    </saml:AuthenticationStatement>
   </saml:Assertion>
</samlp:Response>

Here is an example of an SAML attribute request. Here, there is a query being sent to the attribute authority to figure out if user Ram works in the admin department of test.com.

<samlp:Request MajorVersion=”1” MinorVersion=”0” …>

<samlp:AttributeQuery>

<saml:Subject>
   <Saml:NameIdentifier
      SecurityDomain=”test.com”
         Name=”cn=Ram” />
     </saml:Subject>

       <saml:AttributeDesignator
       AttributeName=”Department”
      AttributeNameSpace=”test.com” />

   </samlp:AttributeQuery>
</samlp:Response>

About the author: Atul Kahate is Head – Technology Practice, PrimeSourcing (the The Global IT Services business from i-flex solutions limited). He has authored 16 books on Information Technology, 2 on cricket, and over 1500 articles on both of these in various newspapers/journals. He can be reached at .

Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code