SAML basics

SAML 2.0 (Security Assertion Markup Language) is the protocol that makes single sign on possible. To get an idea how SAML functions, you could download the Firefox plugin SAML tracer. It adds a viewer window, decoding and showing SAML messages.

When a user logs in, this is what basically happens:

1. The SP sends a message to the IP, asking to authenticate the user.

2. The IP asks the user for a username and a password.

3. If correct, the IP sends an authentication response to the SP saying that the user has logged in successfully, together with a proof that the message was sent by the IP.

We will illustrate this with an example:

1. User wants to read his mail and goes to a webpage like https://mail.google.com/a/my-university.nl.

2. SP generates a SAML request.

3. SP redirects the browser to SURFconext, where the user chooses his IdP (4.) for authentication, which may look like this (abbreviated):

https://idp.uni.nl/sso?SAMLRequest=fVLLTuswEN0j8Q...c%3D

Embedded in the redirection is a SAML authentication request message. This message is compressed (to save space in the URL) and encoded (because some characters are not allowed in URLs). Taken away the encoding and compression, the SAML message could look like this:

<AuthnRequest ID="kfcn...lfki"
 Version="2.0"
 IssueInstant="2013-02-05T08:28:50Z"
 ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
 ProviderName="google.com"
 AssertionConsumerServiceURL="https://www.google.com/a/uni.nl/acs"
>
 <Issuer>google.com</Issuer>
 <NameIDPolicy AllowCreate="true"
  Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
 />
</AuthnRequest>

Simply said this message is: "This is a request from SP. Please authenticate the user and send the result back to SP". For more information about the authentication request click here.

5.The IdP receives this message and will authenticate the user by asking her name and password.

6. After successful authentication, the IP generates a authentication response.

7. The IP sends sends an encoded SAML response to the browser. Decoded, the message looks like this:

<Response
 Version="2.0"
 IssueInstant="2013-02-05T08:29:00Z"
 Destination="https://www.google.com/a/my.uni.nl/acs"
 InResponseTo="kfcn...lfki">
 <Issuer>https://idp.uni.nl/</Issuer>
 <Status>
 <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
 </Status>
 <Assertion Version="2.0" IssueInstant="2013-02-05T08:29:00Z">
 <Issuer>https://idp.uni.nl/</Issuer>
 <Subject>
 <NameID>alice</NameID>
 <SubjectConfirmation ...>
 <SubjectConfirmationData
 NotOnOrAfter="2013-02-05T08:34:00Z"
 Recipient="https://www.google.com/a/my.uni.nl/acs"
 InResponseTo="kfcn...lfki"/>
 </SubjectConfirmation>
 </Subject>
 <Conditions
 NotBefore="2013-02-05T08:28:30Z"
 NotOnOrAfter="2013-02-05T08:34:00Z">
 </Conditions>
 <AuthnStatement
 AuthnInstant="2013-02-05T08:29:00Z"
 SessionNotOnOrAfter="2013-02-05T16:29:00Z >
 </AuthnStatement>
 </Assertion>
</Response>

In essence, it means "This is a message from idp.uni.nl. I have successfully authenticated a user. This message will expire in a couple of minutes".

The message also contains an XML digital signature, proving that the message was sent by idp.uni.nl. The signature was made using a public key algorithm, the public key being embedded in a certificate known to the SP.

8. SURFconext sends new SAML response to the ACS URL of the SP.

9. SP verifies the XML signature, checks if the authentication was successful and if the message is not expired. Then it extracts the user's identifier as known to SP (NameID).

If the last step is OK, Alice is logged in, her mailbox is retrieved and she can read her mail.

Page tree

SAML basics