Problem:
A growing number of applications, all of which have their own authentication mechanisms. Until recently, the authentication store consisted of a database and the user authentication data was pushed to most application authentication stores. The amount of custom code, authentication data movement and data synchronization jobs has become a liability to our stakeholders. Other problems include distributed logs of authentication and authorization info which makes research into potential security breaches difficult.
Solution:
Conversion of applications to use CAS instead of custom or internal authentication mechanisms. This project is joined with a project for the creation of an enterprise active directory and an associated MS FIM identity management infrastructure.
Benefits of CAS:
* More thoroughly tested code authentication code
* Less maintenance required
* Less application specific integrations
* Some common applications have existing support
* Logs consolidated
* Can customize login for some use cases revolving around maintenance windows
I started to work on the CAS part of the project. There were a number of hurdles to work out. My preference was working in Eclipse and CAS is setup to build with Maven. Instead of reinventing the wheel, I decided to try and use an Eclipse/Maven integration combined with our Subversion source repository. This seemed like it should work without problem but then the dark side of open source came out. The maintainers of the integration stopped work on the Subversion support for the integration and decided to only support Git. I was not impressed with the tone of things. Here is a
link to a related conversation. Someone did fork the code and the Eclipse update site for it is
here. Very grateful for that.
I now had functional Eclipse/Maven/Subversion support but I can't say that I find the whole process very intuitive. I was able to get the as delivered CAS code to compile and run fine and I was able to branch it with some basic additions for my organization. I need to further externalize some of the application setup; as I indicate in another post I tend to try to leave most of the configuration in Spring based configuration files stored on NFS storage.
Started to create a Jenkins build for this. I am trying to use the Maven build support but I am not sure how many things must get updated to build only the components I care about. By default, it build all the components.
In-progress and near-term customizations include:
* Authentication with AD
* Initial clustering support
* Currently using Ehcache but am still thinking hard about updating it for JBoss Infinispan. I think this is on the CAS todo list but I don't think it will be difficult to do so.. See if time permits me to work on this.
* DB backed service registry
* Multiple institution branding dynamically selected based on target IP or host. I think branding support/infrastructure improved in CAS 3.5 but not sure of the overall state yet.
Longer term customizations:
* Ability to prevent logins by unprivileged users at certain times to allow easier testing of upgrades and other maintenance and support activities (handle per application and maybe even environment).
Also started prototyping changes to one custom application over to CAS. This application poses some challenges since it has multiple login entry points for 2 distinct sets of users.
Need to research the Google auth/SSO support which is one of our bigger needs now.
[Update 9/9/2012]
* Active Directory authentication working well
* DB backed service registry implemented
* Had a brief thought of trying to implement via a NoSQL solution or some other solution which would make the service registry highly available. On a quick review, this doesn't seem to be as simple as hoped and more research into the registry indicates that availability should not typically be a problem. Leaving this as a future enhancement idea though.
* Have an initial partial conversion of one client application.
* Redirection from application to CAS works.
* Main obstacle to review - current app has 2 different authentication entry points for 2 distinct sets of users. I am hoping that this will not require substantial customization to support. For now, one entry point makes the most sense to convert to CAS. I think that a Java EE filter combined with some load balancer rewrite magic will help maintain the appropriate authentication flows. Can't put many details in a blog on this though.
Next steps
* Need to sort out ticket validation on client.
* Need to work out branding; some apps centrally branded and others branded for 23+ institutions. CAS 3.5.0 branding doesn't appear well documented at this point - am starting to review CAS code.
* Finish and deploy a Jenkins based build to a newly created dev server.