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