How Spring Security hooks to Central Authentication Service (CAS)
Our latest software project used CAS for authentication and single sign-on. I couldn't find any good documentation on how Spring Security and CAS played together. There is some documentation about how to configure your application to use CAS but not much on what messages go back and forth by whom and when.
Normally, we would drop in the CAS war, do a little configuration and use it for single sign-on for a suite of applications. I had a basic understanding of how it worked conceptually, but not really a complete understanding of how it worked in practice. This was okay provided that we didn't run into any issues with authentication or needed to extend CAS functionality.
This understanding gap started to show up when I needed to use Spring Security as the CAS client. I was able able to configure the client easily enough, but couldn't quite get my head around how Spring Security interacted with CAS at a message level. I put together the following diagrams to address that gap.
High Level Collaboration Diagram
This diagram doesn't show the internals of the Spring Security client but it is very helpful if you aren't all that familiar with how CAS works in general. The main takeaways are how involved the browser is in the process. There are a bunch of redirects that happen (really without the user noticing) during an login/authentication. The second thing is step #8. This is the only time where the Application (Spring Security client) talks directly to CAS. This is also why the Application's JVM needs to be accept the SSL certificate of the CAS application. This seems to trip people up.
Sequence Diagram
This diagram has the three main actors in the Spring Security CAS client and shows which classes actually initiate redirects. This is very helpful if you need to modify the CAS application. I put it together as a first step in determining how to add password expiration detection with force password change into CAS instead of having them in each application.



Non-Simple security.xml
This is the real security.xml file that we use to configure Spring Security. Normally we wouldn't need to do this expanded version, but I wanted the channelProcessingFilter to fire (which switches the protocol from http to https) on all non-secured resources. If the concise configuration actually used the filters attribute on the sec:intercept-url element, I wouldn't have to break it all out. It was good to figure out anyway.
-Matt
-Matt
Here's the concise security.xml configuration
Here's the concise version of the security configuration. This isn't something that you would be able to totally copy and paste of course. At a minimum the ROLEs are going to be different, as well as the service and userDetailsService definition.
-Matt