Consuming SAML Identity Authentication - Introduction

Introduction

One of the hot new topics in software development is the idea of a company buying a subscription to a piece of software. Instead of deploying that piece of software internally, with the host of IT needs and challenges that face any sort of deployment, they pay another company to allow them access to that software.

This has many advantages – the client does not need to deal with rolling the application out to many users. This can be especially troublesome if the application is only used once or twice in a two year period – perhaps the application is used to review results of a survey that only occurs every so often or perhaps the application is used to manage the employee's pension plan.

As with anything in software, though, there are disadvantages. The one that this entry is going to focus on is the problem of login propagation. Basically if each system that a client purchases uses a different login and password for the user, this can quickly lead to problems as more and more such systems are purchased. Think about all the online accounts that you have and how many passwords you've ended up with. This has security implications – the more usernames and passwords that a user has, the greater the possibility that they will be written down or made insecure. This is frankly unacceptable if, for instance, the system holds valuable confidential data.

Companies, of course, have usernames and passwords – users use them every day to log into their corporate accounts and do their job. It would be a lot easier if they could share that information with third-parties and use those accounts used for logins. This is, of course, impossible – no company is going to want to share such sensitive information with a provider. Not to even mention the difficulties of keeping that credentials store up-to-date in the face of new users, removed users, and required password changes.

In past years vendors have tried to address this need with proprietary solutions. Netegrity (now owned by CA) released a product called Affiliate Agent, for instance. Users on the way out of the corporate intranet were routed through a portal site. This redirected them to the service with credential information included in the HTTP request. An ISAPI filter runs on the provider's web site that intercepts the request, authenticates the user, and provides information about them in HTTP headers available to the provider's web application. This was a workable solution, though a proprietary one.

With newer, open standards coming out around passing, encrypting and signing information, however, there is now a better solution. Security Assertion Markup Language (SAML) is that solution.

What is SAML?

SAML is a way of expressing information about a user in a secure fashion. This can include pretty much anything – user ids, email addresses, phone numbers – generally speaking whatever can be exposed by the systems linked up with a corporation's security gateway (think LDAP).

SAML itself is a specification defined by the OASIS (Organization for the Advancement of Structured Information Standards) group of several leading companies. The specification itself works with several other standards – XML, XML-Signature, SSL, and (of course) HTTP. These combine to create a secure method for companies to pass credential information to their service providers.

How Does a SAML Request & Response Work?

The lifecycle of a SAML Request & Response is as follows:

1. The user clicks on the link to the provider's site (in this case we'll pretend the url is https://www.provider.com/).
   
2. The web application running on the provider's site looks at the request and realizes that it has no idea who this user is. It redirects the user to a pre-arranged portal site that is hosted by the customer.
   
3. The portal site determines who the user is. This can be done through a username/password combo, the user's domain credentials, or any number of different ways.
   
4. The portal site creates a SAML response – a piece of XML indicating who the user is.
   
5. The portal site signs the SAML response with its private key, including the public key (or not! Some implementations do not include the public key. In this case the customer and the provider will need to exchange that public key. More on this later.
   
6. The SAML response is encoded in base64 and dropped into a HTTP POST request (within the SAMLResponse key) to the original provider's site.
   
7. The provider pulls out the SAMLResponse data, decodes it, verifies the signature, and extracts the user id. Frequently this user id is compared to the provider's list of allowed user ids.
   
8. If the user id validates, the user is allowed into the provider's site to do their work.
   

SAML Responses

Here's an example of a SAML response:

<samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2007-12-20T15:29:18.082Z" MajorVersion="1" MinorVersion="1" Recipient="" ResponseID="SM3b3c34b2352b7fedbaa30f1d9dc5a0c28e697fbe53">

<ds:Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#SM3b3c34b2352b7fedbaa30f1d9dc5a0c28e697fbe53">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>7wS/K/2tMeEWLrPE2hVAxJOoMFI=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>Base-64 signature goes here.</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>Base-64 certificate goes here</ds:X509Certificate>

<ds:X509IssuerSerial>

<ds:X509IssuerName>CN=Trusted Secure Certificate Authority,O=Trusted Secure Certificate Authority,C=US</ds:X509IssuerName>

<ds:X509SerialNumber></ds:X509SerialNumber>

</ds:X509IssuerSerial>

<ds:X509SubjectName></ds:X509SubjectName>

<ds:X509SKI></ds:X509SKI>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

<samlp:Status xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:StatusCode Value="samlp:Success"/>

</samlp:Status>

<saml:Assertion xmlns:SM="http://www.netegrity.com/SiteMinder" AssertionID="SMb65e33e44ef3db1774911aea9b268074bb5fdbe0" IssueInstant="2007-12-20T15:29:18.071Z" Issuer="http://www.netegrity.com/SiteMinder" MajorVersion="1" MinorVersion="1" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Conditions NotBefore="2007-12-20T15:28:48.062Z" NotOnOrAfter="2007-12-20T15:30:48.062Z">

<saml:AudienceRestrictionCondition>

<saml:Audience>http://www.netegrity.com/SampleAudience</saml:Audience>

</saml:AudienceRestrictionCondition>

</saml:Conditions>

<saml:AttributeStatement>

<saml:Subject>

<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion" NameQualifier="www.netegrity.com"></saml:NameIdentifier>

<saml:SubjectConfirmation>

<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Attribute AttributeName="SMContent" AttributeNamespace="http://www.netegrity.com/SiteMinder">

<saml:AttributeValue></saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

<saml:AuthenticationStatement AuthenticationInstant="2007-12-20T15:29:17.000Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">

<saml:Subject>

<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion" NameQualifier="www.netegrity.com"></saml:NameIdentifier>

<saml:SubjectConfirmation>

<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml:ConfirmationMethod>

</saml:SubjectConfirmation>

</saml:Subject>

</saml:AuthenticationStatement>

</saml:Assertion>

</samlp:Response>

In the next post, I'll dissect the components of this request and explain what goes into a SAML response. After that I'll show how, in .NET, you can consume a SAML response, verify it, and pull out the user id.