Gregory Szorc's blog

Evaluating Single Sign-On Alternatives

In a previous post, I raised the need for a replacement single sign-on service for the university and investigated the usage of Oracle's single sign-on product as a viable replacement. The results were discouraging. Therefore, a separate single sign-on product is desired.

The first product to grab our attention was CAS. What really got our attention was the list of CAS clients as well as the list of CAS deployers.

Let's evaluate CAS:

• It is widely used. This means support for the product should be easily available.
• It is built using standards. CAS actions are performed using simple HTTP GET and POST requests.
• We know what CAS does and can modify it accordingly because the product is open source.
• It has plugins for almost every desired usage. The Apache module (for both version 1 and 2) easily install. The modules even work with mod_auth_ldap (I did have to change 4 lines in the source code for this feature, however). If a user doesn't have access to the Apache config, Perl and PHP modules exist to easily integrate your application. For languages without a client yet, designing one is very simple because CAS is built upon standards.
• Using CAS requires you to just know the URL of the login server. There is no need for anyone in ITS to configure CAS to allow you to use it.

So CAS wins big points for being built on standards, easy to use, and easy for ITS to maintain. However, what about the other applications. How do we get the Oracle applications to use CAS? The good news here is that Oracle Single Sign-On can be integrated with CAS. We could deploy CAS as our primary single sign-on service and Oracle's single sign-on would use CAS to authenticate. In addition, other universities have successfully used CAS as the authentication method for PeopleSoft implementations (our ERP system). Webmail could also be modified to use it.

Looking at the big picture, we have two requirements:

1. We must be running Oracle Single Sign-On for the portal


2. We want to maintain a single sign-on service that is easy for clients to use

If Oracle Single Sign-On was the only SSO service, #2 would not be true. The requirement of #2 therefore dictates that we operate a separate and primary single sign-on service. CAS seems to fit that requirement perfectly. The only problem left is integrating Oracle Single Sign-On to work with CAS. Until that solution is put in place, users must settle for separately logging into Oracle products; not a big deal considering this is already the case.

The advantages of using CAS as our central authentication service are great. The usage barrier for CASifying web sites is so low, that system administrators can easily adopt this solution. Deploying CAS requires a one-time effort by ITS. No intervention is required for new applications to use the service.

The solution appears clear. When can we make it official?

You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/2128 .

You very site very nice. Thanks owneros. Best.