CAS Clients

Texas A&M's CAS deployment returns the standard payload so CAS client code from the Apereo Foundation site can be used.

Warning

CAS authentication is considered a legacy protocol and should not be used for new production systems & services. If your system is constrained and can only support CAS (and not OIDC or SAML), reach out to identity@tamu.edu for assistance.

CAS Client Code Samples

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, as it is very different from traditional forms of authentication.

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 can be 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.

  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.

  3. Tell the user who they are. This is good practice, particularly if you think your application may be used in an environment where multiple people might access the same workstation.