Information about integrating CAS with a web site

At Indiana University, there are several different ways for applications to integrate CAS authentication, including login and validation.

Overview

For an in-depth explanation of CAS implementation, see Jasig's CAS 1 Architecture page. At IU, CAS authentication works as follows:

1. Your web application redirects the user to: https://cas.iu.edu/cas/login?cassvc=IU&casurl=http://yoursite.iu.edu
   • cassvc is the IU custom application code.
   • casurl is the URL of your service.

   See Logging in below.

2. The user logs in at cas.iu.edu, and is redirected to your web application at http://yoursite.iu.edu as follows: http://yoursite.iu.edu?casticket=ST-1234-cvbfglkDFGbfbnvbjh-wsa451.uits.indiana.edu

   Note: casticket is equivalent to ticket on the CAS 1 Architecture page.

3. Your web application (yoursite.iu.edu) validates with CAS by sending a request to: https://cas.iu.edu/cas/validate?cassvc=IU&casticket=ST-1234-cvbfglkDFGbfbnvbjh-wsa451.uits.indiana.edu&casurl=http://yoursite.iu.edu

   If the validation is successful, CAS sends back a two-line response with "yes" on the first and "username" on the second. If validation fails, CAS responds with "no".

   See Validating a CAS ticket below.

4. When the user has finished with the web application, you may choose to log the user out of CAS. See Logging out.

Note: CAS at IU is not interoperable with code that speaks the standard CAS protocol; some local customization will be required.

Logging in

The login process begins when a user first requests a page from your CAS-integrated application. Your site will need to redirect the user to the CAS login page, and will also need to communicate (via the URL) what kind of authentication you want CAS to perform with an application code; see For CAS, what is an application code? A common example of an application code is IU, which restricts your application to users with a valid IU Active Directory credential. You will also need to pass the return URL, normally http://yoursite.iu.edu, so that CAS will know where to redirect users upon successful login. A properly formatted redirect URL using the above information would look like:

The CAS server maintains its own state with each user, and can determine if the user has logged in session. If the user has not authenticated yet, CAS requires a valid username and passphrase combination before the user can proceed. If the user had already logged in, the process continues silently.

In either case, once the user has authenticated, CAS redirects the user back to the original application specified by the casurl value, generating and transmitting a unique string called a "CAS ticket"; a CAS ticket may look like this example:

Validating a CAS ticket

Once CAS redirects the user back to your site, the validation phase begins. Your application must now take the newly provided CAS ticket and send a request to CAS to check if the ticket is valid. The validation request must be in the following format (using the application code IU and a return URL of http://yoursite.iu.edu):

Note: The cassvc and casurl parameters passed here to the validation service must match the values passed in the login request.

If validation is successful, CAS sends back a two-line response with "yes" on the first and "username" on the second. If validation fails, CAS simply responds with "no".

Logging out

You can provide a CAS logout with the URL:

However, this is not reliable; the only secure way to log out from CAS is to close the browser. If secure logout is an issue with your service, you should direct your users to close their browsers when they have finished.

Notes

• CAS tickets may be validated only once.
  
  
• All of these requests take place through normal web transfers, either by use of redirects or through standard page requests. All communication with the CAS server is handled via SSL. Applications are strongly encouraged to use SSL on their web servers as well.
  
  
• Applications should maintain their own states with a user, so the login process with CAS should only happen once per session. After the initial login and validation, the application should not have to redirect the user back to CAS within the same session.
  
  
• Compiled modules are available. See CAS Code Samples. Make sure they meet your security needs before using them with your application.

  Note: The CAS ISAPI filter does not work on IIS 7.x, and will not be supported further.

To contact the IMS team, email  ithelp@indiana.edu .