Codenoble

A few years ago when I was working for a university and we were rolling out CAS authentication for our apps. I headed to the internet to read up on anything I could find about CAS. Unfortunately, what I did find was a jumbled and overly complex mess of documentation. So, for the sake of those who will come after me, I'm going to do my best to explain, in as simple terms as possible, how CAS client authentication works. I'm assuming you have at least a basic understanding of HTTP requests, responses and cookies.

Note: There are some more advanced setups that CAS supports such as proxy authentication. This article will only cover the basics.

What is CAS

Nobody enjoys logging into websites. It's, at best, a minor inconvenience. And having to juggle a different username and password for each application just makes things worse.

CAS (Central Authentication System) seeks to minimize the annoyance of passwords by having one page where everybody logs in with one username and password. From then on they will be automatically authenticated with any website within your organization that they may visit.

Google does something similar with their applications. If you go to Gmail and log in, you can go to Google Docs, Google Maps, etc. without having to log in again.

Basic Components

There are two basic components needed to achieve CAS authentication. A CAS server and a CAS client. The CAS server will need to run something like Jasig CAS Server or CASino (I recommend CASino especially if you're a rubyist). For the client side, you have a lot of options. But because I wrote it, and I never miss an opportunity for a shameless plug, I'm going to recommend Rack-CAS.

The Authentication Process

Note: For this scenario, we're assuming you are not logged into the client application or the CAS server.

1. You visit http://app.example.com.
2. The app doesn't know who you are, so it redirects you to http://login.example.com?service=http://app.example.com. That service parameter tells the CAS server where to redirect you back to once you've successfully logged in.
3. The CAS server will show you a login page where you will enter your username and password.
4. Assuming you remember your password, the CAS server will authenticate you, store your username in a session that you are tied to via a cookie for login.example.com.
5. The CAS server then redirects you back to http://app.example.com?ticket=ST-uuddlrlrbas.
6. app.example.com sees that this is a CAS authentication request and sends a validation request to login.example.com/serviceValidate?service=http://app.example.com&ticket=ST-uuddlrlrbas. Note that for security reasons this request doesn't happen through the browser but directly between the application and the CAS server.

7. If the service and ticket parameters are valid, the CAS server responds with an XML formatted service validation response that looks something like this:

    <cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
      <cas:authenticationSuccess>
        <cas:user>johnd0</cas:user>
      </cas:authenticationSuccess>
    </cas:serviceResponse>
   

8. app.example.com then parses this response and pulls the username from the <cas:user> tag and stores it in it's own local session that you are tied to via a cookie for app.example.com. Just as if you had logged in via a traditional login page on app.example.com.
9. At this point you are logged into the application and all interactions with the CAS server are done until the local session on app.example.com expires or is destroyed.

Important details

• Notice that the users password is never seen by app.example.com. Only login.example.com ever sees the password which adds an extra layer of security.
• It's important to realize that there are two sessions going on here. One for login.example.com and one for app.example.com. If either of them are still vaild, the user will still be logged into app.example.com. Only when the sessions for both services expire or are destroyed will the user have to login again.
• CAS single logout exists to solve this issue with multiple sessions. But that's a blog topic for another day.
• Additional information beyond the username can be sent in the validation response from the server. But that is a messy topic, so it will also have to wait for a future blog post.
• This is all standard CAS protocol stuff, but there are other things that certain CAS servers and clients support that are outside of the core standard and they don't always play nice with each other.

Please leave a comment if there are any questions you have about CAS or anything you'd like to see me cover in future a blog post. I've worked with CAS quite a bit in the last few years and I've found there is a shortage of good information out there. So it's something I'd like to revisit in the future.