Single Sign-on with Shibboleth IDP Server

What is Single Sign-on?
Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

Single sign-on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign-on. For example, an environment where users are prompted to log into their desktop, then log into their email using the same credentials, is not single sign-on.

SSO shares centralized authentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.

Common SSO Configurations:

1. Kerberos based - Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT). Additional software applications requiring authentication, such as email client or intranet portals, etc. use TGT to aquire service tickets, proving user's idetity to the mailserver or portal server and thus does not require user to re-enter credentials.
2. Smart card based - Initial sign-on requires use of smart card. Smart card-based single sign-on can either use certificates or passwords stored on the smart card.
3. OTP based - (one time password) - Two-factor authentication with OTP tokens
4. SAML - Security Assertion Markup Language (SAML) is an XML-based solution for exchanging user security information between an enterprise and a service provider. It supports W3C XML encryption and service provider initiated web single sign-on exchanges. The user is called the subject in the SAML-based single sign-on. The identity provider is the one that provides the user credentials. The service provider trusts the identity provider on the user information to provide access to its services or resources. One such SAML based SSO solution is Shibboleth which we discuss below.

Shibboleth Identity Provider
Shibboleth is one of world's most deployed federated identity solutions. The Shibboleth software implements widely used federated identity standards, principally the OASIS Security Assertion Markup Language (SAML), to provide a federated single sign-on and attribute exchange framework. A user authenticates with his or her organizational credentials, and the organization (or identity provider) passes the minimal identity information necessary to the service provider to enable an authorization decision. IDP only provides authentication and not authorization.
 The Identity Provider provides Single Sign-On services and extends reach into other organizations and new services through authentication of users and securely providing appropriate data to requesting services. In addition to a simple yes/no response to an authentication request, the Identity Provider can provide a rich set of user-related data to the Service Provider. This data can help the service provide a more personalized user experience, save the user from having to manually enter data the service requires, and refresh the data each time the user logs onto the service.

The normal Identity Provider process is:

• Accept a SAML authentication request from the Service Provider a user wants to access;
• Authenticate the user against your organization's existing authentication service;
• Collect user data from your organization's existing data stores;
• Apply policy to control what data is released to which Service Provider;
• Securely transmit the collected information to the Service Provider.

Single Sign-on Steps

Step 1: User accesses the Resource

The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, directs them to the service provider in order to start the SSO process.

Step 2: Service Provider issues Authentication Request

The user arrives at the Service Provider which prepares an authentication request and sends it and the user to the Identity Provider. The Service Provider software is generally installed on the same server as the resource.

Step 3: User Authenticated at Identity Provider

When the user arrives at the Identity Provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the Identity Provider authenticates them (e.g. by prompting for, and checking, a username and password) and the user proceeds to the next step.

Step 4: Identity Provider issues Authentication Response

After identifying the user, the Identity Provider prepares an authentication response and sends it and the user back to the Service Provider.

Step 5: Service Provider checks Authentication Response

When the user arrives with the response from the Identity Provider, the Service Provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g. the user's identifier) available to the protected resource. After this, the user is sent to the resource.

Step 6: Resource returns Content

As in Step 1, the user is now trying again to access the protected resource, but this time the user has a session and the resource knows who they are. With this information the resource will service the user's request and send back the requested data.

Federated Single Sign-on

If you have heard about Shibboleth you have probably also heard something about "federations" or "Federated Single Sign-on". The steps above are common to all SSO systems, but some of these systems are designed to only work when the Identity Provider and Service Provider are in the same organization, whilst others are designed to work regardless of whether the two components are in the same organization. Implementations that fall into the later category are said to implement Federated Single Sign-on.
It is not uncommon that a given Service Provider may wish to work with more than one Identity Provider (e.g. commercial services with multiple customers, resources used by researchers at multiple organizations), and likewise a given Identity Provider might wish to work with multiple Service Providers. When a group of Identity and Service Providers agree to work together, this group is called a federation.

There have been security concerns pertaining to Federated SSO (which is gaining alot of popularity in the web sites these days) one example excerpted from Wikipedia is reproduced below:

The problem we see now is that many websites are adopting Facebook’s “Connect” and OpenID to allow for one-click logins to access a website. You sometimes don’t even have the choice of making a separate account on that site, meaning you can’t “opt out” of these SSOs. Sure, your information stays safe with that site, but it’s also stored within a central database under Facebook’s control. While there’s nothing wrong with this, there’s just too much risk involved in putting all your sensitive data from all over the web into one massive identity bubble.

—"Does Facebook Federation Have Your Best Interests At Heart?

Deploying Shibboleth Identity Provider

1. Install tomcat (or one of the supported web containers) and deploy Shibboleth WAR.
2. Configure IDP login handler for one of the supported authentication types. Simplest will be to have user authenticated based on their IP address as described here - https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthIP 
3. Configure IDP Server - https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfiguration 
1. Service provider (application requiring SSO) identified as relying party 
2. Generate self-signed certificate for IDP server and import to IDP server’s trust store. Used to enable SSL for tomcat.
3. Export Service Provider's server certificate and import it to IDP server.
4. Export IDP server certificate and import it to Service provider server.
5. IDP server metadata URI (which identifies the URI for the service provider where authentication assertion needs to be sent). For example,
1. IDP metadata URI - https://:8443/idp.xml
2. Service provider assertion consumer URI - https:///assertionconsumer

One alternative to Shibboleth (SAML based) is to use OpenID based solution like OpenID4Java, which i will capture in a following post.