SSO

The following write up covers the results of some research I did for work regard SSO. The purpose was to give a brief high level report of what I had been investigating. It was not meant to cover all technologies investigated or implementation strategies in depth. I thought it might be of some use. This study was done in January of 2008.

SAML SSO Solution

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between security domains. SAML is used to try to solve the Web Browser Single Sign-On (SSO) problem, which is finding a way to allow a user to use several different services without needing to log in several different times with different usernames and passwords. The main componenents of a SAML solution are a service provider, which provides SAML assertions, and an identity provider, which consumes SAML assertions. The Service Provider and Identity Provider are configured to know that they can trust each other.

A SAML Assertion contains:

•  A packet of security information consisting of header information. The header contains the name of the identity provider and other information such as issue and expiration dates. 
• The name of the subject.
• One or more statements.  The two most important statement types are authentication statements and attribute statements.

A principal (often the user) must be enrolled with an identity provider. The identity provider is expected to provide local authentication services to the principal. The identity provider can use any method it wants for authentication, such as LDAP or Active Directory. The principal always communicates with the Service Provider to determine authentication. If the principal is not authenticated, the Service Provider will redirect the principal to the Identity Provider. The Identity Provider will log the principal in, commonly by displaying a log in page shared by all services. Once the Identity Provider has authenticated the principal, it will create an assertion that is provided to the Service Provider. The Service Provider will provide an artifact, which may be used to obtain the assertion, to the the principal. Of course, failure to authenticate the user will provide in failure to obtain access to the server. This allows Single Sign On Functionality, as any principal from any domain can authenticate themselves through Service Provider calls. A domain can check the status of a user by providing the SAML artifact and examining the resulting SAML assertion. More commonly, the Service Provider will redirect the principal to the service they requested after the Service Provider determines the principal is authenticated.

In addition to SAML, the Liberty ID-FF standard was investigated in addition to SAML. Liberty ID-FF is an extension to SAML version 1.0. Its primary difference is that it provides what Liberty called a circle of trust, which allowed policies to be defined to let domains know they can trust each other. SAML version 2.0 represents the convergence of Liberty ID-FF and other proprietary extensions, as well as early versions of SAML itself.

Sun Access Manager

Sun Access Manager was the first application I evaluated as a SAML Service Provider and Identity Provider. Tutorials proved to be difficult to follow and many supporting technologies were required to use Sun Access Manager for SAML purposes. Ultimately, I switched to the newest version of Sun Access Manager, which was OpenSSO. OpenSSO was not only being actively developed, but it already contained the supporting technologies Sun Access Manager had required for SAML.

OpenSSO

OpenSSO is Sun's open source access management and federation server platform. It is configured via an admin web interface and contains a rich Java API. The Java API defines communication between clients and OpenSSO. The Java API also contains interfaces so that developers can design plugins, or modules, to OpenSSO. The downside to OpenSSO is its complexity and flexibility. OpenSSO is so huge and does so much that it takes a lot of time to learn about it, despite only needing to do one small thing. OpenSSO is a combination of several different Sun Technologies and so has a very large amount of documentation. OpenSSO is also fairly new, although its underlying technologies are not, which make it difficult to find independent tutorials. Sun's OpenSSO documentation can be found at http://docs.sun.com/app/docs/coll/1767.1.

Authentication Service

The Identity Provider provides authentication. The identity provider to be used was OpenSSO, which provides authentication services through plugins. Three built-in plugins included LDAP, Active Directory, and OpenSSO's internal data store. There were many other plugins along with an interface to create custom authentication plugins. This provided confidence that OpenSSO could interact with any client's authentication service. LDAP, Active Directory, and OpenSSO's internal store were all investigated so that they could be used for flexibility demonstration purposes. Tutorials were found for all three services and all authentication services were set up successfully.

An SSO Solution

The identity provider will be OpenSSO. This will require an authentication service to be configured and populated. OpenSSO will also need to be configured as an identity provider. No plugins will need to be written unless the authentication service chosen to be used is not supported, which is an unlikely case.

The Service Provider can be either OpenSSO or a custom server. Creating a custom server would give a project more control, but would require writing code to parse SAML artifacts and assertions, as well as code to communicate with the Identity Provider. The SAML specification is not trivial, so this would be a lot of work to do correctly. It would probably be easier to use OpenSSO as the service provider. This would likely require writing OpenSSO plugins to circumvent certain redirections. This will also require a lot of OpenSSO configuration.

Code will also need to be written to retain artifacts, transport artifacts, and communicate with Service Provider to obtain assertions. Code will also need to be written to parse assertions, but this will most likely be accomplished through the OpenSSO API.

Weblinks

The following is a brief collection of web urls with information to help someone to implement the strategy described in the SSO Solution section.

A Good Overview of SAML: http://en.wikipedia.org/wiki/SAML
Directions to using OpenSSO as an IdP with Google as an SP, which will allows you to set up a working demonstration:
http://blogs.sun.com/wahmed/entry/how_to_federate_with_google
Directions to configuring OpenSSO as an SP: https://www.enterpriselab.ch/wiki/doku.php?id=public:opensso_sp_shib20_idp
OpenSSO SAML API: http://docs.sun.com/source/820-3739/index.html

Open SSO Token

Although the SAML approach is viable, it would take too much time to implement at this point in time. The introduction of a Service Provider and an Identity Provider would have added a significant amount of work, time spent debugging, and time spent spent documenting, especially in conjuncion with OpenSSO. A much less time consuming approach would use OpenSSO Tokens through the OpenSSO API. In this approach, only one OpenSSO instance is required. The OpenSSO instance will consume authentication requests and provide OpenSSO Tokens. It will also consume OpenSSO Tokens to provide OpenSSO assertions, which are collections of information about the principal whose authentication produces the OpenSSO token. Using the OpenSSO Token is a much simpler Single Sign On solution.

The downside is that SAML is a standard where the OpenSSO Token is not. However, using the OpenSSO Token still allows interaction with whichever authentication service a client is using. Furthermore, SAML functionality could be added given more time.