SAML is the abbreviation for Security Assertion Markup Language and is an authentication and authorization system. While that’s the technical definition, it doesn’t really explain what SAML is.
The most venerable system is basic authentication, which is providing a username and password to get authenticated and authorized. Basic authentication has these drawbacks:
- Users must sign into each unique system
- Users must reset their password often
- Users must use a strong password
SAML resolves some of these issues. With SAML, a user signs into one system and a SAML token is created. Then, as the user navigate to other systems, if the other system is part of the SAML hierarchy, the user is authenticated and authorized into the system via the SAML token. In this way, the user does not need to sign into each system in the SAML hierarchy. Instead, the user sign into system "a" and then is granted access to systems "b", "c", "d", et cetera.
Let's see how Shibboleth could be used as your SAML system.
Before we get into SAML, we first need to establish a users repository. Let's go with LDAP. For this tutorial, let's set up an OpenLDAP server on Linux and create a user (john.doe). Refer to the LDAP section of our WalkThroughs page. So now our heirarchy has a single system, the LDAP server. Hooray!
Identity Provider (IdP)
As the name implies, the Identity Provider is the system that validates a users identity. Technically, the Identity Provider is not the system that contains users identies. That's some other system (Active Directory, LDAP, et cetera). Instead, the Identity Provider knows if you are or are not validated with the system that contains your identity. Thus, the next leg of the journey here is going to take some time, as there are 3 systems at play here (Tomcat, Shibboleth, LDAP).
If everything goes according to plan, your IdP log should record a successful authentication against LDAP, something like this:
Authentication succeeded for dn: uid=john.doe,ou=people,dc=example,dc=com
Service Provider (SP)
Let's say www.example.com/secure is your current basic authentication page, and you want to update this page to be authenticated and authorized via SAML.
Once you've configured www.example.com/secure to be authenticated and authorized by the Service Provider, navigating to www.example.com/secure will return this most unsightly response. This occurs because the other primary component of the SAML hierarchy is missing, the Identity Provider (IdP).