I frequently need to build multiple applications that share a common login system. When these applications are behind a firewall and using AD or LDAP, single sign on is relatively easy, most of the problems have been worked out and there are even standard libraries built into frameworks like .NET to help you. But, when your application is outside the firewall, web based and has no AD or LDAP user store, that is another beast entirely. My go to for that is SAML with a set of SQL tables.
In this set of posts I am gong to build a ZF2 Composer module that is based on SimpleSAMLphp that will authenticate a user using a SQL table. My intention is to integrate SimpleSAMLphp into a ZF2 vendor module touching SimpleSAMLphp as little as possible. This is so that code changes made to SimpleSAMLphp can easily be integrated back into the JStormes/SAML composer module.
Understanding how SAML Redirect and Post data is transported
While SAML has many technical details, the key aspects I run into when dealing with SAML in the real world revolve around the Redirect and Post transport. By breaking down how data is sent using SAML I hope to save you some time debugging issues.
The easiest way to understand the SAML transport is to go back to the a basic HTML form:
[pastacode lang=”markup” message=”Submit a hidden form” highlight=”” provider=”manual”]
<form action="demo_form.php" method="post">
Click Submit to send the hidden data to the server. <br>
<input type="hidden" name="hiddenstuff" value="hidden value">
<input type="submit" value="Submit">
While trivial most HTML developers will recognize the form will simply submit some hidden value back to the server. Now, consider a slightly more interesting form.
[pastacode lang=”markup” message=”Sending hidden data to a remote server” highlight=”1″ provider=”manual”]
<form action="http://www.domain.com/demo_form.asp" method="post">
Click the submit button to send the hidden data to the server.<br>
<input type="hidden" name="hiddenstuff" value="hidden values">
<input type="submit" value="Submit">
This version can post the form outside your web site, to a server located anywhere in the world. This is key to understanding SAML, as this is the basis of how SAML communicate between sites. This technique is referred to as HTTP POST binding. (https://www.oasis-open.org/committees/download.php/25607/sstc-saml-binding-simplesign-cd-02.pdf)
While there is much more involved in in SAML (Encryption, Base-64 encoding, etc.), the communication mechanism is pretty simple.
Actual SAML page:
[pastacode lang=”markup” message=”Actual SAML page” highlight=”2″ provider=”manual”]
you must press the Continue button once to proceed.
<form action="http://ServiceProvider.com/SAML/SLO/Browser" method="post">
<input type="hidden" name="RelayState"
<input type="hidden" name="SAMLRequest"
<input type="hidden" name="Signature"
<input type="hidden" name="SigAlg"
<input type="submit" value="Continue"/>
Using this technique data can be passed between servers letting the browser carry the data in the form post.
Some SAML terminology
- SP – Service Provider, the site the user is trying to access. The thing providing some service for the user.
- IdP – Identity Provider, the site that is going to ask the user for an id and password. This is where the login page lives.
- Assertion – Something said about the user.
- Authentication Assertion – The user is authenticated at this time.
- Attribute Assertion – Something about the user, a role, email address, list of friends…
- Authorization Decision Assertion – The user can access something or not.
So lets put a typical web application sign on into SAML speak:
Our website about cat www.aboutcats.com is our SP (Service Provider). The website www.allaboutcats.com is our IdP (Identity Provider) that knows who the users are.
When the user wants to sign into www.aboutcats.com she is redirected to www.allaboutcats.com where she enters her user id and password. If she enters her user id and password correctly, she is redirected back to www.aboutcats.com where attribute assertions are passed back.
Now if our user wants to go to www.catfriends.com that also uses www.allaboutcats.com as an IdP, she would not be asked again for a password as she has already signed in, she would just be redirected back to www.catfriends.com with any attribute assertions requested.
That, in a very abbreviated form, is SAML transport.
In Part 2 of this series we will build the Composer package to manage this interaction.