If you are not familiar with SAML and Single Sign On (SSO), check out our article on understanding SAML and SSO.

LDAP

Before we get into Shibboleth, 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). 

• Install Tomcat application server and ensure Tomcat is running.
• Setup Tomcat to use SSL / HTTPS
• Install and setup the Shibboleth Identity Provider.
• Configure Shibboleth Identity Provider to authenticate against 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. 

• Install HTTPD web server.
• Lets install and setup the Shibboleth Service Provider.
• Then configure www.example.com/secure to be authenticated and authorized by the Service Provider.

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