skip to main content
Infrastructure Division of Information Technology

Authentication & Authorization Services

Central Authentication Service (CAS)

CAS Client Code

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

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. We will be expanding this section based on feedback from both CAS developers and users.

  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 customers' 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 for login and logout, see and

  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 (with a very narrow set of use-cases) that can take advantage of a user not knowing whose account they are logged in with.

Discussion about these topics on the 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. Practices that gain consensus support will be added to this page.