If you are not familiar with SAML and Single Sign On (SSO), check out our article on understanding SAML and SSO.
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).
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).