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.
Note: CAS at IU is not interoperable with code that speaks the standard CAS protocol; some local customization will be required.
Logging in
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
application code IU and a return URL of
http://yoursite.iu.edu):
Note: The cassvc and casurl
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'.
Further notes:
- 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
session.
- Compiled modules are provided below for both Apache and
IIS. Please make sure they meet your security needs before using
them with your application.
To contact the IMS team, email ithelp@indiana.edu.
Last modified on September 16, 2009.
