Next: Shibboleth installation and configuration.
What is SAML
I am currently dealing with a project that involves single sign-on (SSO) and SAML protocol. Single sign-on means you enter your credentials once, and then use your identity on multiple web sites. The web sites must talk between each other to verify your identity without exposing your user name and password. Two leading protocols for that purpose are OAuth and SAML.
An interesting twist is that we already had a quasi-SAML SSO implementation written long time ago by some consultants from a galaxy far, far away, but it fell quite short of actually implementing the standard. SAML is an XML-based standard coming from Oasis, like SOAP, WSDL, WS-Security, etc. Like most XML-based standards coming from OASIS, SAML is a verbose soup of XML tags governed by complex rules, which are easily misunderstood. Some of the errors in our old implementation came from simply not reading the standard carefully enough, but others arose from fundamental misunderstandings, which I will cover later.
Shibboleth
To make sure our new implementation is indeed standard compliant, I needed a SAML-speaking piece of software that does not come from our company. I found Shibboleth, which is open source, free, and seems to be relatively widely used. Unlike HTTP, you cannot just go to an existing SAML web site and start talking to it. In order to star talking, the parties must be specifically registered with each other. Dynamic discovery protocols do seem to exist, but since we are talking about security here, no one will blindly accept SAML messages from strangers.
There are two basic roles in SAML: Identity Provider (IdP) and Service Provider (SP). Identity provider knows who the user is and what are his/her properties. Service provider is a web site that uses Identity Provider to authenticate the user, and then provides (or does not provide) some services based on the user’s properties. E.g. as a Service Provider, I can design a section of my web site available only to users who have property “SecurityClearance” with value “Secret” or “TopSecret”.
Shibboleth can act as both IdP and SP. We are implementing Identity Provider, so my goal was to install Shibboleth SP and make sure our software can talk to it.
The role of SAML attributes
An important point that was not clearly understood at the time our quasi-SAML implementation was implemented is that IdP is responsible only for authentication, but not for authorization. I.e., IdP only can tell who the user is (authentication, but it does not have a final say in what the user can do (authorization). It can come pretty close by providing corresponding attributes (clearance=’none’), but it is the SP who makes the authorization decision.
In our quasi-SAML implementation we sent “authentication failed” response when the user was not authorized to execute services provided by the counter party. This was a bad idea. Shibboleth, as well as other implementations like Apache Mellon, consider failed authentication as an exception. They insist on configuring access based on attributes.
SAML does not have exhaustive definition of attribute names: an IdP can send any attributes they want. SP must know what these attributes mean and make authorization decision based on them.
The role of metadata
Each SAML entity (be it IdP or SP) must provide metadata which is a static XML document whose format is defined by one of the books in SAML standard. The metadata describes the entity ID, what roles it supports, its cryptographic certificate, and the like. Most SAML software products and libraries need to see counter party’s metadata file in order to communicate with that counter party. Your implementation cannot be called SAML compliant if you do not provide metadata.