5 December 2006 JA-SIG Atlanta CAS Kiosk

I presented an impromptu kiosk at the Atlanta JA-SIG conference and here share the slides and notes.

This was less a presentation and more the slides I used at a computer kiosk to assist in talking to passers-by about CAS. Note that most to all of the slides in this kiosk deck are lifted from prior CAS presentations.

CAS is enterprise single-sign-on for the web. Users authenticate to CAS. Only CAS, not the various user-facing web applications, sees end user passwords. The web applications receive assurance of user authentication from CAS rather than from themselves examining passwords.

CAS is the trusted intermediary brokering secure sessions between end users and web applications.

In the bad old days each application would present its very own login form.

And so if you had several web applications, you'd have several login forms. Possibly, eventually, one of the applications will be compromised by the Adversary.

CAS reduces this to just one centralized login form.

One function of a portal is to aggregate content. In order to aggregate content from various sources, the portal needs to aggregate authentication, authenticating on behalf of the user to the places where the interesting information lives.

To accomplish this, CAS implements n-tier authentication, where CAS authenticates the user to the portal and the portal-in-the-context-of-the-user's-secure-session to various backing sources of information.

This slide deck includes two examples: network registration and IMAP email.

The network registration web application provides a login button.

Clicking the login button takes you to the CAS server where you can accomplish login.

When CAS redirects back to the web application, it places a token (ticket parameter) on the request.

The target web application receives the ticket and validates it with the CAS server.

The user didn't give her password to the target web application. Instead, she gave the target web application a transient ticket which the application validated with CAS to verify that the user had given CAS her password.

Browser authenticates with CAS using username and password, receiving a ticket. Browser accesses web application and presents ticket but not password. Application validates the ticket with CAS.

Note that this slide is animated in the attached PowerPoint file and the animation does help with making this comprehensible.

The browser initially accesses a web resource (application). The web resource eventually decides that it would like the user to be authenticated, and redirects the user to CAS with the identity of the web resource specified as S. The user accomplishes authentication with CAS in some way or another (typically by presenting a password). CAS issues a secure session cookie C so that it can recognize the browser on subsequent requests, putting the "single" into Single Sign On. CAS redirects the user to the web resource at the URL S bearing the ticket T as a request parameter. The web resource validates that T is intended to authenticate the user to S with CAS.

The user is authenticated to the application without presenting her primary credentials to the application, by means of very transient ad-hoc CAS ticket credentials. The ticket can be thought of as a really short lived password created and consumed just for this occasion.

Tickets have meaning in the CAS protocol only by virtue of the CAS server recognizing them and responding to them. They are longish random strings. They come in a number of flavors. Ticket Granting Tickets are bound up in Ticket Granting Cookies which CAS attempts to store into the user's web browser (securely) so as to recognize the user on subsequent requests to authenticate to other applications without requiring another presentation of primary credentials to CAS. Service tickets are tickets for the purpose of authenticating user to application. Proxy granting tickets are the key by which web applications themselves request proxy tickets for authentication of web application to another web application.

When I click the "Login using Yale NetID" link, what will happen?

CAS does not display the login screen. It reads the secure cookie from the browser, recognizes it, and issues a service ticket on the basis of that recognition, all without prompting for a password. Of course, if the application had requested that CAS requrire primary credentials for the purpose of authenticating to this application, CAS can do this. The "Single" convenience is available but not required.

uPortal validates the service ticket presented to it and at the time of validation requests a proxy granting ticket.

Now the user is authenticated to the portal. Further, the portal can use its proxy granting ticket to proxy authentication to backing information providers to gain information to inform the user experience.

uPortal uses its proxy granting ticket associated with this user session to obtain from CAS a proxy ticket directed at the mail service. It requests the mail service (a simple bridge webapp converting IMAP email to XML suitable for uPortal consumption). The mail XML service receives the proxy ticket, validates it, and itself obtains a proxy granting ticket. The mail XML service uses its proxy granting ticket to get a proxy ticket for accessing the IMAP server on behalf of the user. It presents this proxy ticket to the IMAP server as the password field of the IMAP protocol. The IMAP server delegates to PAM_CAS to validate the proxy ticket.

The happy result is that a simple XSLT channel in the portal, using the CasConnectionContext, can display my latest email.

Not shown on this slide: user obtains service ticket from CAS for accessing uPortal and presents it to uPortal. uPortal validates ticket (thereby authenticating the user to the portal) and at that time obtains a proxy granting ticket. uPortal uses the proxy granting ticket to obtain from CAS a proxy ticket for accessing the email servlet. uPortal requests XML of the email servlet presenting this proxy ticket. Email servlet presents proxy ticket to CAS, thereby authenticating the portal on behalf of the user to the email servlet. At that time the email servlet obtains from CAS a proxy granting ticket.

And now picking up with this diagram: the email servlet presents its proxy granting ticket PGT to CAS along with the identity S of the service to which it wishes itself to authenticate. CAS returns a proxy ticket PT intended to authenticate the email servlet to the IMAP server. The email servlet presents the NetId and proxy ticket to the IMAP server as the username, password in the IMAP protocol. The IMAP server validates the proxy ticket with CAS, obtaining a description of the proxy chain that led to that proxy ticket. The IMAP server decides it accepts this chain and allows this to authenticate the email servlet to it to establish an IMAP session.

The email servlet uses the IMAP session to read the email. It converts the email into XML and presents it back to uPortal.

Let's take another example, that of Horde IMP (a free and opensource webmail program) using proxy tickets to access the IMAP server. In this case the end user has presented a service ticket T to IMP, acquired by bouncing off of CAS and possibly presenting primary credentials if this has not been recently done to establish an authenticated session with CAS. Imp validates the service ticket with CAS, presenting also its own identifier S so that CAS can inform it whether the ticket matches the service. During this validation the IMP webmail application requests of CAS and receives from CAS a proxy granting ticket PGT. IMP presents the PGT to CAS in order to obtain PT a proxy ticket. IMP presents the proxy ticket to the IMAP server. The IMAP server uses its CAS PAM module to validate the proxy ticket with CAS, examining the end user and intermediary identities.

Let's look at how this works in uPortal in a little more detail. A Channel calles getCasServiceToken() on the CAS security context, typically by means of a CAS-specific LocalConnectionContext implementation. The CAS security context will inquire of the CAS ticket receptor servlet to get that proxy ticket. The proxy ticket travels up the call stack back to the channel, which presents the proxy ticket to some resource out on the web to which it wishes to proxy. The channel resource validates the proxy ticket with CAS and, informed by its response, responds to the channel which considers this response in composing its presentation to the end user (or other behavior).

The CAS ticket receptor servlet is able to obtain a proxy ticket from CAS because it has the proxy granting ticket. It has the proxy granting ticket because CAS sent it a proxy granting ticket at the time of service ticket validation when the user authenticated to the portal. However, it's important to use the right proxy granting ticket, otherwise you might accidentally proxy the wrong end user's authentication. Proxy granting tickets are linked to user sessions by proxy granting ticket I-owe-yous (pgtIou). Each user's CAS Security Context has the pgtiou associated with the user authentication because it is the component that (or is bound up in the system that) validated the service ticket with CAS when the user authenticated to the portal.

When I say that CAS is enterprise single sign on for the web, the enterprise bit isn't there just because it sounds good. It's there because CAS has these n-tier authentication enterprise-architecture-friendly features.

CAS is a concrete (Java) server implementation.

And CAS is a constellation of client libraries that talk to the CAS server.

My personal favorite uPortal CASification approach uses my personal favorite CAS client. This is kind of nice in that it re-uses configuration know-how about the CASFilter and makes CASifying uPortal a little more like CASifying other Java web applications.

Acegi is powerful generic authentication and lightweight access control for Java web applications. It supports CAS.

Lately, Rutgers and especially Scott Battaglia have been doing a lot of the heavy lifting on CAS.

Have questions about CAS? CAS has active email lists for discussion of the project and its usage. A lot of help is available free of charge in the open in that forum -- and before you ask your question, you might review the CAS website, the email archives, and the JA-SIG wiki. However, if you're looking for more formal or deeper assistance, a number of commercial service providers are emerging around the CAS project and you might even explore with Unicon whether your CAS-related needs are something Unicon can help you with.