SSO with SAML

Overview

We frequently get requests from clients to integrate our Tag:CMD system which a SAAS offering (Software As A Service) with their internal LDAP system. The purpose of the Blog is to describe how we approach SSO (Single Sign On)and to illustrate how it can be implemented.

The first part of the post is generic to SSO, after which, in a second post, I will illustrate an implementation using the SAML Post Profile, the Apache XML Security library and ColdFusion. (Since the Apache library is a java library, the java code is almost identical).

SSO has  a number of advantages:

  • Users want a single account and password to work on all their work systems
  • Reduces user maintenance in the application
  • Ensures user information is kept up to date
  • When users change employment their accounts are automatically deactivated

What is sometimes harder to appreciate is that its not as simple as calling their LDAP server. When evaluating a SSO solution we are looking for some key elements:

  • The clients server does the authentication to avoid
    • storing of users passwords in our database
    • forwarding of users passwords though our servers
  • The clients server sends us the following information
    • Users identity
    • Basic information about the user (e.g. Name, email etc)
    • Servers identity
    • Time stamp
  • Signatures, certificates and/or secret keys are used to protect against
    • Modification of the information
    • Replay of the information at a later point in time 
  • The system is decoupled so we don’t need a dedicated VPN or back channel to the users server

There are a number of standards for SSO including

  • OASIS: SAML
  • Liberty: ID-FF
  • OpenID
  • Etc

SAML

Many of these use SAML to exchange information. SAML looks complicated and verbose. Essentially its made up of a set of statements, called SAML Assetions. To this we add elements to provide identity and ensure the statements haven’t been modified.

The following illustrates the basic elements. Start with the user identity

<saml:AuthenticationStatement>
    <saml:Subject>
        <saml:NameIdentifier>DavidRutter</saml:NameIdentifier>
    </saml:Subject>
</saml:AuthenticationStatement>

This is incorporated into what is called a SAML Assertion; we can add time properties to this to define its validity period.

<saml:Assertion IssueInstant="2007-11-04T14:04:24Z">
    <saml:Conditions
        NotBefore="2007-11-04T13:59:24Z"
        NotOnOrAfter="2007-11-04T14:14:24Z"/>
    <saml:AuthenticationStatement>
      <saml:Subject>
        <saml:NameIdentifier>DavidRutter</saml:NameIdentifier>
      </saml:Subject>
    </saml:AuthenticationStatement>
</saml:Assertion>

The next steps involve signing the SAML assetions to verify who they came from and that they haven’t been tampered with. There are 3 parts to this:

  • The signed information
  • A signature of the signed information
  • A keyinfo to describe what was used for the signature

We create a digest of the SAML assetions using the secure SHA algorithm so ensure the SAML can’t be modified

<ds:SignedInfo>
    <ds:DigestValue>/UlguevI2sppqGHnuZQV</ds:DigestValue>
</ds:SignedInfo>

Sign the digest to prove the identity. The signing is done using the private key of a certificate.

<ds:SignatureValue>
ID0Pr3EMyqvLilnZ0YNzt3z8GEyz6029V11rq
</ds:SignatureValue>

We add a keyinfo section to identify what was used for the signature. This can be the actual certificate.

<ds:KeyInfo>
    <ds:X509Data>
        <ds:X509Certificate>MIIC6jCCAd</ds:X509Certificate>
   </ds:X509Data>
</ds:KeyInfo>

Putting the signature altogether looks something like this:

<ds:Signature>
  <ds:SignedInfo>
    <ds:DigestValue>/UlguevI2sppqGHnuZQV</ds:DigestValue>
  </ds:SignedInfo> 
  <ds:SignatureValue>
ID0Pr3EMyqvLilnZ0YNzt3z8GEyz6029V11rq
  </ds:SignatureValue>
  <ds:KeyInfo>
    <ds:X509Data>
        <ds:X509Certificate>MIIC6jCCAd…</ds:X509Certificate>
    </ds:X509Data> 
  </ds:KeyInfo>
</ds:Signature>

 

Profiles

Assuming we have a library capable of creating the SAML, the next part is to define how the user, the system creating the SAML (the issuer or IdP) and the system receiving the SAML (the service provider or SP)  interact.

There are a number of different profiles, the simplest architecturally is the Browser Post Profile.

  • User goes to an intranet site and is authenticated.
    (either automatically via, or using a username/password)
  • User clicks on a link to take them indirectly to the external service
    e.g. http://intranet/SamlRedirect?goto=ExternalServiceUrl
  • The link first goes to an intranet hosted page which generates the SAML, does a 64bit encoding, and generates a
    a HTML page with a javascript redirect to the external service
  • The users browser will automatically do a HTP POST of the SAML to the external service
  • External service decodes and verifies the SAML, and logs in the user automatically.

The html will look something like the following:

<body onload="saml.submit()" >
<form name="saml"
    method="post"action=http://serviceProvider/SSO/POST/ …>
    <input type="hidden" name="SAMLResponse" value="response" />
    …
    <input type="submit" value="Submit" />
  </form>
</body>

Implementation

This will be covered in a second post on how to do the encoding and decoding in Java and ColdFusion.

Links

See this wikipedia article for more information and links

One Response to “SSO with SAML”

Leave a Reply