Evaluating Oracle Single Sign-On
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.
- We are using it because it is required by the portal.
- It requires manual intervention every time a new client wishes to use it. Isn't this a reason why we are investigating alternative?
- The Oracle products easily integrate with it. Hooray! No more separate logins for the portal and the calendar.
- Writing external programs to authenticate against it requires the use of a C or Java SDK. (I can hear the screams of agony now).
- 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.