For integrating Google Apps with an existing SSO, a simple delegation of authentication is not enough.
If nothing is done, the Shibboleth IdP will require that the user authenticates locally each time he or she accesses the Google Apps domain, even if he or she already did so earlier. This, obviously, is not the desired SSO behavior. In true SSO, the user should be required to authenticate only once, typically when first accessing the IS daily and later, the authentication should be automatically taken care of.
One of the most commonly used SSO mechanisms in companies is the Kerberos technology that comes with Windows. We shall briefly present the principles on which Kerberos relies and then explain how to configure Shibboleth so that the IdP uses Kerberos for authentication.
Ke rberos is a communication protocol that allows computers in non-secured networks to mutually prove their identity to one another. The technology is based on symmetric cryptography and needs a trusted third party. For a Kerberos deployment, this trusted third party is the so-called Key Distribution Center (KDC), itself composed of two logically distinct entities: the Authentication Server (AS) and the Ticket Granting Server (TGS).
The KDC handles a database of secret keys, each of them being known only to the KDC and to the entity to which it is associated. Possession of one of these keys is used to prove the identity of its owner.
The basic mechanism behind Kerberos is an exchange of tokens to prove the identity of stakeholders. The security of the mechanisms relies, partly, on the short period of validity of the tokens.
Here is how a Kerberos authentication works:
- A user authenticates with the AS, which sends back a timestamped token T1.
- The user sends this token T1, provided by the AS, to the TGS. The TGS authenticates it and sends back a request to access a service.
- If the user was granted appropriate rights for accessing the requested service, he or she will be given another token T2 from the TGS.
- The users presents the token T2 to the service as a proof that he or she is entitled to access it.
Accessing the AS is usually performed using a password with a long period of validity. The token (T1 above) returned by the AS after this basic authentication can be reused several times to get other tokens (T2 above) from the TGS to access other applications.
A full description of setting up a SSO with Kerberos is beyond the scope of this book. We will assume here that such a setup has already been done and shall only describe the main tasks involved in configuring Shibboleth to use Kerberos rather than a traditional login password page.
Co
nfiguring an IdP with Shibboleth is a complex and technical topic. A dozen XML configuration files are involved. What interests us here is the login.config file, which describes the authentication mechanism to use.
The actual authentication process is taken care of by the Java platform on which Shibboleth is running. This security mechanism, among others, is normalized under the name Java Authentication and Authorization Service (JAAS). It is thus essential to master the JAAS configuration of a Java platform, a topic for which numerous tutorials are available.
Here are the basic steps to follow to configure Shibboleth to use Kerberos:
- In the first step, we must configure Shibboleth to define a so-called Login Handler (a Shibboleth concept) that tells Shibboleth to use the JAAS mechanism from the Java platform.
- In the second step, we must specify, on the Java platform itself, meaning in the JRE configuration, which JAAS Login Module should be used. It is here that we specify that the Kerberos Login Module should be used, rather than, say, the LDAP Login Module.
- More details are given in the online configuration guide of Shibboleth and in the JAAS guide of the Java platform.