Information about integrating CAS with a web site
At Indiana University, there are several different ways for applications to integrate CAS authentication, including login and validation.
For an in-depth explanation of CAS implementation, see Jasig's CAS 1 Architecture page. At IU, CAS authentication works as follows:
- Your web application redirects the user to:
cassvcis the IU custom application code.
casurlis the URL of your service.
See Logging in below.
- The user logs in at cas.iu.edu, and is redirected to your web
application at http://yoursite.iu.edu as follows:
casticketis equivalent to
ticketon the CAS 1 Architecture page.
- Your web application (yoursite.iu.edu) validates with CAS by
sending a request to:
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.
- When the user has finished with the web application, you may choose to log the user out of CAS. See Logging out.
Note: CAS at IU is not interoperable with code that speaks the standard CAS protocol; some local customization will be required.
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 For CAS, what is an application code? 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
http://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:
The CAS server maintains its own state with each user, and can determine if the user has 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.
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:
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
IU and a return URL of
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".
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.
- 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
- Compiled modules are available. See CAS
Code Samples. Make sure they meet your security needs
before using them with your application.
Note: The CAS ISAPI filter does not work on IIS 7.x, and will not be supported further.
To contact the IMS team, email
Last modified on February 06, 2013.