Building a ZF2 SAML Composer module Part 1

SAML Draft logo

SAML Draft logo

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”]


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”]


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. (

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”]


Note the onload JavaScript, that automatically submits the form, and the fallback “Continue” button if JavaScript is unavailable. Also note the full URL in the action field of the form action.

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 is our SP (Service Provider).  The website is our IdP (Identity Provider) that knows who the users are.

When the user wants to sign into she is redirected to where she enters her user id and password.  If she enters her user id and password correctly, she is redirected back to where attribute assertions are passed back.

Now if our user wants to go to that also uses 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 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.


No Responses

Leave a Reply