The aim of SSO techniques is to avoid the need for users to authenticate each time they use a new application. The first section reviews the main issues related to this question. The federation of identity among several security realms is the main topic here. The second section presents the basic concepts of the SAML standard that will be necessary to understand federation of identity and authentication delegation when introducing Google Apps into an enterprise IS. The next section is about using a local ID repository for authenticating users within a Google Apps domain. Finally, the last two sections address two other connected topics: integration of Google Apps in an existing SSO and using Google Apps as an ID provider.
There are numerous issues related to requiring users to authenticate several times, usually once for each new application. First, there is the obvious discomfort of a tedious repetition of authentication procedures that, moreover, often vary from one application to the other. This discomfort can even lead to a decrease in productivity.
A more serious concern, at least in an enterprise context, is the multiplication of passwords that are required. Most users are not able to remember this plethora of passwords, a problem that is compounded when they are asked to change them often. What usually happens then is that they gather all passwords in one place easily accessible to themselves and… to others! The absolute zero of security is reached when a post-it with a list of passwords is stuck on the screen…
SSO (Single Sign On) techniques attempt to solve these issues. All such techniques contain two inseparable elements. First, there is a central ID repository (a database, an LDAP directory, a file, and so on) that people use to authenticate, usually once a day, when they first access the information system. Second, the SSO mechanisms relate this central security context with the many security contexts specific to the various applications, whether these are web applications such as the Google Apps or classical standalone applications running on the user's desktop.
Establishing this link between security contexts is a delicate and complex matter. On the one hand, trust relations must be established among the entities that provide the authentication (IdP: ID Provider) and those which consume it (SP: Service Provider). On the other, the parameters, security contexts, and authorizations should be transmitted from one context to the other in a seamless way for end users.
Summarizing, here is a list of issues that any SSO solution should address:
- Allow the use of several passwords for different applications
- Allow automatic scaling when the number of applications in the SSO domain grows
- Ensure the privacy of parameter exchanges among the various security contexts associated with the different SPs
- Define a federated identity by relating several local identities
- Make sure that no correlations can be established between the activities of any given user in two different security contexts belonging to the same federated identity
- Never propagate security information in an uncontrolled way from one security context to another
- When sharing parameters between security domains occurs, users should be given the possibility to express their consent or their refusal
- Impose no specific authentication technology
- Ensure interoperability between technologies
- Allow the use of certificates to establish trust relationships among IdPs and SPs
- Allow each SP to control access to its own resources
This is where the SAML 2.0 standard comes in: its aim is to bring lasting solutions to all issues related to establishing a federated identity. Currently, the reference open-source implementation is Shibboleth.