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?

Many of you know about login.case.edu. It makes your lives much easier because now you only have to enter your password once for numerous web services. However, there is a problem with the service: it is too complicated. It is not too complicated for the average user, but for the people who implement it. Just look at the hoops you have to jump through to get it working on your own server. What's more is that it relies on a web server module (not everybody has access to the web server config files) and requires somebody in ITS to manually do work every time a new client wishes to use it. What is needed is an alternative. Well, we are already running an Oracle Single Sign-On product, so let's use that! OK, let's evaluate the Oracle product.

1. We are using it because it is required by the portal.
2. It requires manual intervention every time a new client wishes to use it. Isn't this a reason why we are investigating alternative?
3. The Oracle products easily integrate with it. Hooray! No more separate logins for the portal and the calendar.
4. Writing external programs to authenticate against it requires the use of a C or Java SDK. (I can hear the screams of agony now).
5. The module mod_osso appears to only be available for Oracle's Application Server. Does it work with IIS? No. Does it work with your standalone Apache? I don't know either. Judging from a Google search, I'd say it isn't promising. Most importantly, does it work with mod_auth_ldap? Well, we don't know. If it doesn't, there is nothing we can do because the module is closed source.

In summary, we are being forced to use Oracle Single Sign-On, but it works well with the Oracle Applications. No matter what we decide to do, we will have to use this product. If we decide to make it the only SSO service for the university, a significant amount of effort would be required for every new application deployed to use it. Would system administrators make this effort to configure it, or would they take the easy way out and just resort to the tried and true LDAP authentication? Also, any department that uses IIS to host web applications would be unable to use the service. Do we really want to deploy a single sign-on service that only a subset of the university can use? In my next post, I will explore alternatives to Oracle Single Sign-On and how they could integrate with the Oracle applications.