Introduction to SAML for Managers
SAML allows your users to be authenticated and authorized without direct interaction with your web site. It does this by creating a trust relationship between the site and a trusted third party who vouches for the identity of the user. This article explains both how this happens and what the additional benefits are.
What is SAML?
SAML stands for Security Assertion Markup Language. However it doesn’t stop there, SAML is:
- An XML format for communicating security information.
- A protocol for authentication and authorization.
The XML Format
The XML format is used to describe the properties a user has associated with them, for example their username and the roles or teams they are in within your organization.
That is a little simplistic but its the basis of everything. The other main points about the format are:
- The information in the document should be digitally signed.
- There may also be the certificates for authenticating the signatures.
- There is a valid from and to date and time in the document.
- The target of the Service Provider or the Identity Provider is specified in the document.
The rest is all just additional properties of the user.
The protocol however has lots of different profiles, as they are called in SAML or use cases for the rest of us, in this introduction I will just explain two of these to get you started.
- Web Browser Single Sign On Profile.
- Enhanced Client Profile.
As with pretty much any Single Sign On the communication between the parties should be made over secure channels and for this SSL is used.
For the Identity Provider to be able to state that it knows you it asks you to authenticate with it, this could be NTLM or Kerberos when you log into Windows and may be completely transparent or it may ask you for your username and password.
Both parties should sign their messages, the Service Provider its AuthNRequest and the IdentityProvider its Response.
Before going into the details however I think a brief intro to the terms used in SAML would be helpful.
Service Provider SP
This would be your Intranet site which needs you to be authenticated before allowing you to access its content.
Identity Provider IdP
The identity provider is for example your domain server, the machine that when you login to windows would verify your username and password. This computer because it knows you can vouch for your identity and the roles you have.
This is a databank that keeps all the information together related to the user, for example LDAP / Active Directory.
Relying Party Trust
This is a trust relationship that has to be configured between the IdP and the SP. It defines the referrer URL, the destination URL and a definition of the information that should be shared. Basically though it simply tells the Service Provider to trust the information it receives from the Identity Provider and vice versa.
Web Browser Single Sign On Profile
Web Browser Single Sign On is, put simply, what happens when a web page is protected and the browser has to login on your behalf to allow you access to it. So lets see how it works.
- The user tries to access a page on the Intranet site (Tomcat in the diagram).
- The server checks if they already have a session with it, when it finds they haven’t it creates a request for information from the Identity Provider
- It sends this via the user to the IdP and the user authenticates with the IdP if they have not already done so.
- The IdP then asks the Metadata Aggregator LDAP for the information it needs about the user.
- The LDAP server gives the IdP the information it asked for.
- The IdP gives the user a token (an official document) containing a series of statements about the user, that is signed by the IdP, to the SP.
- The user then requests the page from the Intranet site but this time supplying the token it has been given by the IdP.
- The Intranet site (Tomcat in the diagram) verifies the token and then creates a session for the user and returns the page they asked for.
Enhanced Client Profile
Enhanced Client Profile is similar to the above case but with a few subtle differences.
If you immagine your company portal where you have your personal data, account information and customer information on a single screen as in the following diagram.
The Service Providers are the WebServices. Between the end user and the service is a portal which acts as a go between and calls the services on behalf of the end user. The user has to be authenticated and authorized to access the data being supplied by the web services and therefore the portal sends the requests to the web service on their behalf.
The diagram below shows how this works.
- The Intranet site (Tomcat in the diagram) invokes the web service.
- The service sends a PAOS (Reverse SOAP) request to the Intranet site.
- The Intranet site unpacks the request and sends the AuthNRequest it contains on to the IdP as a delegate or on behalf of the end user.
- The IdP has already authenticated the user and so retrieves their information from the Metadata Aggregator LDAP as before and creates a document containing this information, a token, which it sends back to the Intranet site.
- The Intranet site then sends a SOAP/PAOS response to the service that contains the token.
- The service validates the token and then returns the data originally requested by the Intranet site.
Benefits of SAML
Below is a summary of the benefits of SAML.
- The interactions between all parties are secured via SSL.
- The Service Provider doesn’t need to synchronize user credentials and roles.
- The Service Provider has no knowledge of the users credentials.
- The authentication and authorization is based upon a trust between the Identity Provider and the Service Provider.
- The Service Provider can verify that the document containing information about the end user came from its trusted Identity Provider by checking the certificates are from the Identity Provider.
- The Service Provider can also verify that the document has not been modified by checking that the signatures in the document are valid.
I will be covering Digital Signatures in another article in the near future. In that article you will see how signatures can be both created and validated.