When an application would like to authenticate users with CAS, it will use a CAS client along with a small amount of code to interact with this client. Many clients are available including a client for uPortal, AuthCAS for Apache along with clients written in Java, Perl, PHP, Ruby, etc.

To insure that the web application does not require access the user’s credentials, authentication with CAS is a two step process.

When a new user initially logs into an application they won’t have established a session with the application. Instead of displaying a login form asking for the username and password, the application (via the CAS Client) will redirect the browser to the CAS login page.

CAS then authenticates the user. If the authentication fails, the CAS login page is displayed again with an error message. So until authentication succeeds, the user will not be returned to the application. If the user is not sure how to proceed at that point, there are help desk links on the CAS login page. Once the user authenticates successfully, CAS will redirect the browser back to your application. CAS knows where to redirect to via a {service} parameter that you append to the CAS login url.

When CAS redirects the authenticated user back to your application, it will append a {ticket} parameter to your url.

The ticket returned to your application is opaque, meaning that it includes no useful information to anyone other than the CAS Server. The only thing that your application can do is send this ticket back to CAS for validation.

CAS will then either respond that this ticket does not represent a valid user for this service, or will acknowledge that this ticket proves authentication. In the later case, CAS will also supply the user’s NetID so that you know the identity of the user.

The application must provide its own session management. Once the user is authenticated, your application should keep track of this fact within a session so that you don’t have to reauthenticate them with the CAS Server. Typically this would be the same as if you authenticated the user directly from your application.

Through the myRutgers portal, CAS offers a single sign-on facility. Once the user has logged into myRutgers, the user does not need to supply their password to login to other applications using CAS. This is accomplished with a Ticket Granting Ticket cookie that CAS sends back to the browser when they initially login to the myRutgers portal.

For applications that deal with especially sensitive data, the application can opt out of the single sign-on facility by providing the {renew=true} parameter to the CAS login page.

Each application should provide their own logout facility which will invalidate the session and require the user to re-authenticate into the application. Note that if they are using SSO through the myRutgers portal, they will not have to re-enter their NetID and password.

For more information on the details of CAS, see the architectural papers on the CAS site.