Information about integrating CAS with a website

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

Important:

When integrating CAS authentication with your application, follow these best practices:

  • Applications using CAS must operate entirely over TLS (i.e., the casurl must be an HTTPS URL).
  • Enabling HTTP Strict Transport Security (HSTS) is highly recommended.
  • To be sure they are authenticating to IU's CAS, users must be able to see the URL https://cas.iu.edu/. Therefore, applications must redirect to CAS and not render the login page inside an iframe or use other similar techniques.

If you come across a page that does not adhere to these best practices or otherwise seems suspicious, follow the instructions in At IU, how do I report a suspected information or information technology (IT) security issue?

On this page:


Overview

At IU, CAS authentication works as follows:

  1. Your web application redirects the user to:
      https://cas.iu.edu/cas/login?cassvc=IU&casurl=https://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 https://yoursite.iu.edu as follows:
      https://yoursite.iu.edu?casticket=ST-1234-cvbfglkDFGbfbnvbjh-wsa451.uits.indiana.edu

    Note that 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=https://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 2.0 at IU is fully interoperable with the standard CAS protocol. Because standard CAS 2.0 does not require an application code, it will default to IU AppCode. However, the CAS 1.0 validation assertion will return "<username>/r/n" instead of the Unix-style "/n" only.

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 At IU, what are CAS application codes? 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 https://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:

  https://cas.iu.edu/cas/login?cassvc=IU&casurl=https://yoursite.iu.edu

The CAS server maintains its own state with each user, and can determine if the user has a 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.

The following is some quasi-code to help show the process of logging in if the user is not authenticated:

if (!$authenticated) {
  $_SESSION['CAS']= true;
  header("Location:https://cas.iu.edu/cas/login?cassvc=appCode&casurl=https://pathForYourApplication");

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:

  https://yoursite.iu.edu?casticket=ST-1234-cvbfglkDFGbfbnvbjh-wsa451.uits.indiana.edu

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 https://yoursite.iu.edu):

  https://cas.iu.edu/cas/validate?cassvc=IU&casticket=ST-1234-cvbfglkDFGbfbnvbjh-wsa451.uits.indiana.edu&casurl=https://yoursite.iu.edu

This snippet of code provides instruction to validate you, if the user is authenticated, by getting your CAS ticket and seeing if it's good:

  if ($authenticated) {      
    //validate since authenticated   
    if (isset($_GET["casticket"])) { 

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".

Note:
The ticket must be validated within two seconds.

Logging out

You can provide a CAS logout with the URL:

  https://cas.iu.edu/cas/logout

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

  • Your casurl value must be URL encoded. Replace any non-ASCII characters with a percent sign ( % ) followed by the appropriate hexadecimal digits (e.g., replace a space in your URL with %20 ). For a complete list of ASCII character codes, see ASCII Code - The extended ASCII table. For more about URL encoding, see the w3schools.com HTML URL Encoding Reference.
  • 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 with PHP on Webserve. Make sure they meet your security needs before using them with your application.

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

  • If you have an IU GitHub account, you can access these CAS Integration Examples. For information on GitHub at IU, see At IU, what is GitHub, and how do I use it?

To contact the Identity Management Systems (IMS) team, email  ithelp@iu.edu .

Note:

To stay informed or provide feedback about Indiana University's Central Authentication Service (CAS), or to ask questions about developing with IU CAS, use the cas-discuss-l mailing list. To subscribe, send email to cas-discuss-l-subscribe@iu.edu.

This is document atfc in the Knowledge Base.
Last modified on 2017-05-04 14:34:25.

  • Fill out this form to submit your issue to the UITS Support Center.
  • Please note that you must be affiliated with Indiana University to receive support.
  • All fields are required.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.

  • Fill out this form to submit your comment to the IU Knowledge Base.
  • If you are affiliated with Indiana University and need help with a computing problem, please use the I need help with a computing problem section above, or contact your campus Support Center.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.