13 February 2007 Tucson JUG CAS presentation

I had the privilege of presenting on the Central Authentication Service at the Tucson JUG meeting in February. This article reviews and discusses the slides from that presentation.

Warner Onstine and Duffy Gillman deserve credit for drawing me into the Tucson JUG experience. My introduction to the JUG was a lovely holiday dinner that's apparently an annual tradition. I missed the Google CSS talk in January and Warner's groovy Groovy talk in March, but I hope to be able to make it down to Tucson again for this in future months.

CAS is a downloadable, deployable, free opensource Java-implemented central authentication server, protocol, and constellation of client libraries (in a variety of programming languages besides Java). Ultimately it presents a login screen to your end users allowing them to centrally authenticate to disparate web applications.

I worked with CAS during my stint in Yale's Technology & Planning group. Being a casual systems programmer at Yale was great fun, but I've since moved out to scenic Phoenix, Arizona where I'm a software developer for Unicon, Inc.

I got involved in the CAS project in much the way that many people get involved in opensource projects, becoming incrementally more involved through activity on the lists, documentation in the wiki, working on uPortal CAS integration libraries, a new release of the Yale Java CAS Client, and participating in the CAS 3 project. Since then I've had less time for CAS and I wasn't too surprised to find I've become a "developer emeritus" rather than a current developer on the CAS project.

Actually, as I understand it, he's not fully in some technical sense a lawyer at this point. But he went to law school and is looking to be a legal academic. I figure law's pretty similar to software engineering in that precision is important.

This list isn't complete and I don't mean to snub anyone I've left off.

There are a number of deployers of the Central Authentication Service, both in higher education and in other domains. Since registration with the CAS project is optional the online listing of deployers significantly understates the deployment base.

Note that ESUP-Portail has standardized on CAS, so there are a bunch of French universities using it.

CAS is single sign on. I'd like to motivate that by discussing multi-sign-on. Multi-sign-on involves each web application presenting its own user credential entering authentication experience. It's inconvenient, in that the user has to type in these credentials over and over. It's insecure, in that the user ends up doing uncompelling things like storing the password into the browser.

In the most naive example, each application manages its own accounts and credentials. Many users will use the same usernames and passwords over and over, though, just to keep things manageable.

Applying some engineering to mutli-sign-on, you might centralize user accounts. This is a Good Idea. Now the user has only one username and password within your institution, stored in something like LDAP, and all these applications use it.

Is this single sign on? There's only one username and password, right? No. This is a start, but not yet the single CAS is looking to give you.

All the applications to which a user authenticates by typing a username and password receive that password.

If the Adversary compromises any application in the institution, he or she can capture passwords as they are presented to that application. Since account management has been centralized, that captured password is reusable across a number of applications.

The system is single point of failure with many single points to choose from. It is only as secure as the weakest application on the network.

Don't beat up the decision to centrally manage accounts too badly. Things aren't much better in the case where each application manages its own credentials, since many users will choose to re-use credentials across applications and even if they don't, many users won't create secure credentials in each and every case. In general the fewer passwords you make users cope with the more able they'll be to apply security rigor to those passwords.

A solution to this problem of many applications touching the end user's primary credentials and thereby being potential points of system-wide security breach is to introduce a central authentication service to serve as the single login form, the single application trusted to touch the end user's credentials. Perhaps, in Arizona parlance, a sheriff to bring law and order to town.

Here's how this conceptually works. The end user authenticates via password to CAS once and thereby authenticates to the web application she really wants to access without sending the password to that application. The application validates the user's identity with the CAS server. CAS serves as a trusted intermediary between the end user('s web browser) and the web application.

Now let's dive into talking about tickets. The attached PowerPoint includes this and other slides animated.

First, the web browser accesses the web application. The web application presents a hyperlink or issues a redirect such that the web browser accesses CAS, specifying S, the URL of the Service (web application) to which the user desires to authenticate. The end user (via the web browser) interacts with CAS until CAS is convinced of the end user's identity. This usually involves the user presenting a username and password, but in theory could involve other authentication mechanisms and in practice also involves C, a ticket-granting cookie. This cookie is the secure session identifier by which CAS recognizes the browser on subsequent authentication requests, putting more "single" and more convenience into single-sign-on.

Once CAS recognizes the user, it issues a redirect to get the browser back to S, the URL of the service the user's trying to access, with an additional request parameter T, a Service Ticket. Service Tickets are short-term one-time-use authentication tokens.

The web application presents S and T to the CAS server, which if all goes well responds back with the NetID identifier of the end user that has been authenticated. If T is not valid or does not match S, then CAS instead responds with an error message.

The end user's identity reported by CAS, the web application provides an authenticated user experience to the end user. Since the end user trusted CAS with her password, and the web application trusted CAS to validate an authentication token, the user was able to authenticate to the application by authenticating to CAS, all without presenting her password to the web application.

If you've understood all this (and it is easier to understand with animations, so do consider taking a look at the attached presentation files), then you may be able to answer this question: why must the application present S, the identifier of the service, to CAS on ticket validation?

The application must present S, and CAS must validate S, to prevent illicit proxies: the web application taking S and using it to access some other application rather than presenting it to CAS for validation.

Each application needs to know its own identifier URL and present this to CAS with the ticket, essentially asking CAS, "does this service ticket authenticate to this service?" This prevents the Adversary from successfully presenting the service ticket used to access one (compromised) application for access to another application.

If you don't get that first pass, don't worry. However, this digression demonstrates a nice property of CAS: this sort of thing has been thought of and handled.

With CAS implemented, web applications no longer touch end user credentials. CAS becomes the single application touching passwords (and whatever credential store is backing CAS).

Previously, when the Adversary compromised a single application, he or she would acquire passwords reusable across the enterprise. With CAS, when the Adversary compromises a single application, the compromise does not necessarily spread to other applications since that compromised application is not touching end user credentials. CAS becomes the single point of security failure, rather than all applications being potential points of failure. This allows the institution's security staff to focus their efforts on particularly securing the CAS server and other core applications. This doesn't mean security for each application isn't important, only that the consequences of security breaches are mitigated.

Centralizing authentication is great, but what about portals? A typical trick portals use to go get interesting information on behalf of the user is to forward end user credentials to go log into other applications.

Here's the typical password replay diagram. User provides password to portal which provides it to several channels which provide it to backing services to go get interesting information. Notice the passwords proliferating all over the place.

How can a portal authenticate an end user's session without forwarding end user credentials?

Here's where CAS really shines. There are a number of solutions to single sign on (sometimes called "initial sign on") for the web. Few of them also include such a handy service-to-service authentication facility.

The first steps are like before. The user really wants to access the web application, but gets directed to CAS for that pesky authentication business. Authentication to CAS accomplished one way or another, CAS redirects back to the web application with T, a Service Ticket. The application presents T, S the service identifier, and pgturl an https:// callback URL whereat CAS is to send a Proxy Granting Ticket. CAS generates and sends a Proxy Granting Ticket along with a paired identifying PGTIOU to the PGTURL. CAS then responds with the authenticated NetID and the PGTIOU.

The application validating the service ticket now has a PGTIOU. If it has access to the implementation of the https:// URL specified as the PGTURL, it can use that PGTIOU to lookup the actual Proxy Granting Ticket.

The Proxy Granting Ticket grants proxies on behalf of the identified PGTURL. In this way server-side SSL certificates are leveraged to authenticate the web application to CAS. Only the application actually at https://secure.unicon.net/someApp/casCallback can obtain a PGT in the name of https://secure.unicon.net/someApp/casCallback. No other application is at that URL to receive the PGT. The Adversary cannot intercept the PGT in transit because the connection is over https:// and the Adversary will have difficulty impersonating the URL because it will not have a valid SSL certificate.

Personally, I find this approach elegant. It leverages something the application had to have anyway (an SSL certificate) rather than requiring introduction of another element into the mix, such as a client-side SSL certificate or a shared secret.

Now that the application has a Proxy Granting Ticket, it presents to CAS the PGT along with S, which is now the identifier (URL) of the back-end application ("service") to which the application desires to proxy. CAS validates the Proxy Granting Ticket and gives the application a Proxy Ticket (PT). The web application presents the Proxy Ticket to the back-end application, which validates it along with its own identifier S with CAS. If it's valid, CAS responds with the identifier of the end user whose authenticated session is being proxied as well as the identity of the proxying web application (the URL of the PGT) (and that of all other applications in the chain, in the case where this is chained.)

The back-end web application considers the proxy chain. CAS can tell it authentically the identities of who it is dealing with. It is dealing with the PGTURL web application proxying the authentication of end user NetID. The back-end application needs to decide whether it has anything to say to the proxying application about the user. It might decide that the proxying application should not be authorized to know anything. Or it might choose to respond with interesting data.

Supposing it responds with interesting data, the proxying web application can then consider that data in composing its response to the end user's web browser (or do whatever else it would like with that data.)

Note that this protocol allows the intermediary web application to proxy authentication to the back-end web application only in the context of a real user session. It cannot arbitrarily query back-end applications because, without the involvement of the end user, it cannot obtain a PGT for that end user. This is a nice property of the system, allowing application developers to collaborate on data release from back-end systems to web applications such as portals without giving the portal developers arbitrary access to query back-end systems. I can be empowered to build a system that presents to you highlights of your email or your library account status without being given the ability to arbitrarily query your email or library record.

Let's consider the case of a CASified IMAP server and CASified IMP. The browser presents a service ticket to the IMP web application as before. IMP presents that service ticket to CAS, specifying an https:// callback URL for receipt of a proxy granting ticket, and in fact receives a proxy granting ticket. It uses that Proxy Granting Ticket to obtain a Proxy Ticket for access to the CASified IMAP server. It then presents that Proxy Ticket to the IMAP server as the password in the IMAP protocol. The IMAP server validates it with CAS (typically via a CAS PAM module, which is configurable with the set of trusted proxying applications so that email is not released to any application that might obtain a proxy ticket.)

This www.unicon.net article doesn't do justice to the Tucson JUG presentation, because that presentation included questions and interesting side discussions throughout. However, I did close the presentation by asking for questions, and will close this article in the same vein: you can get involved in asking questions about, discussing, trying out, using, and advancing CAS. You can comment on this article on this website with a free self-registered account. The CAS project has an active discussion list. And of course if you'd like to inquire about how Unicon might help you with your CAS needs, that sounds like a conversation worth having.