Central Authentication Service (CAS)

CAS Client Best Practices

Texas A&M's CAS service allows all university students and system employees log in to a single site, and use that login at any number of CAS-enabled sites on campus. This single-sign-on model presents a number of unique opportunities and challenges to developers.

When you write an application that is CAS-enabled, it joins a community of hundreds of applications from around the university. Just like any community, it helps if we all follow some basic guidelines to be respectful of our users and other applications.

1) Do not log users out of CAS. This is the most common and contentious topic, as it is counterintuitive. There are a few reasons for not logging a user out of CAS:

  • It inconveniences users. One of the most useful features of CAS is that it allows you to log in once and access multiple resources. You should not assume that a user is done with their CAS session because they have logged out of your application.
  • It implies single-sign-out. CAS is a single-sign-on service. It does not provide single-sign-out, so users are still logged into any other CAS-enabled services that they used during that session. Users should be encouraged to close their browsers completely when they are done using services.
  • In many cases, what you really want is renew=true. If you are calling the logout page to force a user to re-authenticate before accessing a resource, you are not using the service correctly. CAS provides a mechanism for forcing re-authentication. By including renew=true in the query string of the redirect to the login page, CAS will prompt the user to enter their username and password again before returning to your service. This provides "verification" of the login without impacting campus members' access to other applications.

2) Use landing pages that are not CAS-enabled. Landing pages give your users a clear view of the application they are visiting prior to logging into CAS. This allows them to make an informed decision before logging into your site. It also gives you a place to send users after logging them out of your application that can provide additional guidance. For an example of landing pages see http://google.tamu.edu/ and http://gateway.tamu.edu/.

3) Tell the user who they are. This is a good practice in general, particularly if you think your application may be used in an environment where multiple people might access the same workstation. Additionally, there is a class of attacks that can take advantage of a user not knowing whose account they are logged in with.

Discussion about these topics on the tamu-auth@listserv.tamu.edu mailing list is strongly encouraged. And as you think of other best practices for CAS developers, please share them with the rest of the community for discussion.