Article Discussion Edit this page History

Central Authentication Service

Case has deployed rubycas, an implementation of JA-SIG's Central Authentication Service, or CAS, to allow services to easily authenticate users.

[edit] Using CAS

Users can log into CAS at https://login.case.edu/cas/. Users can log out of CAS at https://login.case.edu/cas/logout. If a user logs into CAS, he or she can be logged in to any application that participates in the service without again specifying his or her password for a period of up to 8 hours.

[edit] Frequently Asked Questions

[edit] Why do I need to change my password before I can log in?

CAS integrates with the university's password policy requirements. If your password is expired and you attempt to log in, CAS will inform you of such. You will be given a link to change your password.

[edit] Why should I close my browser when I am done?

When you log in to CAS, a cookie is stored in your browser that allows you to be automatically logged in to other sites. This cookie is set to expire at the end of your browser's session. So, when you close your browser, this cookie no longer exists and you can no longer be automatically be logged in to any more sites without specifying your password again.

It is possible to log out of CAS by visiting https://login.case.edu/cas/logout, however, this is not a secure form of logging out! Some sites may still have you recorded as logged in through the use of cookies on those specific sites. Closing your browser is the easiest way to guarantee that the next user of a computer will not be surfing the web under your identity.

[edit] Authentication versus authorization

When you access content, there are two phases you must go through to be allowed to access it: authentication and authorization. Authentication is proving that you are who you say you are. Authorization is determining whether a proven person is authorized to access something. CAS handles authentication. By logging in to CAS, CAS can authenticate your identity to participating services because you have authenticated yourself to CAS and CAS is trusted by the services that use it. CAS does not handle authorization to individual services. It is up to the individual services to determine if a user is allowed to access them.

[edit] How do I obtain the user's name, status, etc

CAS merely authenticates a user. All the services know is that a username, abc123 is accessing their site. CAS does not provide information about users to accessed services. However, all is not lost. This information is contained within the university's LDAP server. It is possible for end-services to query the LDAP server for information about these users to control and customize service behavior. Some examples are displaying the user's name, filtering content based upon user's role within the university (student, staff, faculty, etc), grade level of student (freshmen, sophomore, junior, senior, etc). To find information on how to do this, consult the LDAP article.

[edit] Why should I change my existing service to use CAS

In addition to the normal benefits of only having to supply credentials a minimal number of times, using CAS with your web service helps fight phishing attempts. By providing a uniform login experience, users will be wary of providing their credentials on web sites inconsistent with the login.case.edu work flow. Using CAS, also, ensures that credentials are always passed over the network in a secure format.

[edit] I have more questions, who do I contact

Send an e-mail to sso-admin@case.edu

[edit] How CAS Works

[edit] Basic overview

When a user accesses a site that uses CAS, that site redirects the user to CAS (login.case.edu). Once CAS has verified a user's identity, it forwards them back to the original site. CAS attaches a unique ticket number to the URL of the protected service. The protected service sees this ticket. It sends this ticket to CAS. CAS tells the protected service whether the ticket is good and if so, the Case ID that was used to obtain the ticket. The protected service reacts accordingly, allowing access if the ticket is good.

[edit] Detailed overview

When you log into CAS at https://login.case.edu/cas/, a cookie is saved in your browser. This cookie contains a unique ticket number that identifies you to the CAS server. Every time you access https://login.case.edu after you are logged in, your browser automatically transmits this cookie to the web server. CAS reads the cookie, looks up the ticket in its database, and identifies you.

CAS clients behave a little differently. Say you access http://blog.case.edu/mt/mt-cas.cgi. When you load up that page, the page requires that you be logged into CAS to access it. How does this work? The page redirects you to

https://login.case.edu/cas/login?service=http://blog.case.edu/mt/mt-cas.cgi

via an HTTP Location header. Once CAS has verified you are logged in, it sends you back to the URL specified in the service parameter, in this case http://blog.case.edu/mt/mt-cas.cgi. There is, however, one small change. CAS appends a service ticket to the URL, like

http://blog.case.edu/mt/mt-cas.cgi?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc

The CAS client sees that the ticket parameter is defined and knows the user has just come from https://login.case.edu. The CAS client then queries

https://login.case.edu/cas/serviceValidate?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc&service=http://blog.case.edu/mt/mt-cas.cgi

The CAS server replies with an XML document that describes the service ticket. Some of the values returned include whether the ticket is good and the username associated with the ticket.

 
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>abc12</cas:user>
    <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</cas:proxyGrantingTicket>
  </cas:authenticationSuccess>
</cas:serviceResponse>

Alternatively, the CAS client can query

https://login.case.edu/cas/validate?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc&service=http://blog.case.edu/mt/mt-cas.cgi

This will return a two line document. The first line will say yes or no. The next line (only present if the first line is yes) will be the username associated with the ticket.

In short, when a user requests access to an application that is CASified, that user gets whisked away to the CAS server. Once they are logged in, the client is returned to the application with a unique service ticket. This is a personalized ticket, good for only one use, and a short period of time that will gain you access into the application. The CAS client verifies this ticket by talking to the CAS server and if everything checks out, it lets you in.

[edit] Proxy authentication

CAS also supports proxy authentication. Proxy authentication is useful for middle-tier applications that need to connect to another application on behalf of the user. For example, you visit a portal that requires you to be logged in to CAS. This portal shows information from Blackboard, which uses CAS. Proxy authentication can be used so the portal can obtain information from Blackboard without the user explicity logging in to Blackboard.

Proxy authentication can be very confusing and can also lead to security concerns if not implemented properly. A good source on proxy authentication is the official documentation on proxy authentication, the CAS 2 Architecture, and the CAS protocol. Before using proxy authentication, please e-mail sso-admin@case.edu and let them know what you are doing. This is for your own benefit and the data security of your customers.

[edit] CAS Implementation Best Practices

[edit] Use Caching

Many of the clients listed below use some form of caching. Without caching, the CAS client will redirect the user to the CAS server for every request to obtain a new service ticket. This places more load on not only the CAS server, but your web server as well. Also, it takes a little longer for every page access to load because the user has to process 3 HTTP requests and your web server has to verify the ticket with the CAS server. Assuming a negligible page load time under normal conditions, it takes about 5x longer to view a page.

To eliminate this bottleneck, you should store a cookie on the client's browser that tells your server that they are logged in. This cookie should contain a ticket that you can map to a user. Most CAS clients do this transparently. Some clients, such as the PHP client, store this information in the user's $_SESSION.

[edit] Don't Log the User out of CAS

Some CAS clients have a logoff function that will actually log the user out of CAS. This should be avoided! Don't confuse local application logoff and CAS logoff. If the user logs out of the local application, they are simply transitioning from registered user mode to anonymous user mode. If a user logs out of CAS, they will be forced to supply their username and password again. A simple way to check for logging out of CAS is to look for a request to https://login.case.edu/cas/logout. If this URL is accessed by a client, they will be logged out of CAS.

[edit] Configuring Applications to Use CAS

CAS is being used because it supports many clients for authentication. A fairly complete list of clients is available. To use CAS for authentication, you need to know the following parameters:

Host: https://login.case.edu
Context: /cas/
Login URL: https://login.case.edu/cas/login
Logout URL: https://login.case.edu/cas/logout
Validate URL: https://login.case.edu/cas/validate (CAS protocol version 1)
Service Validate URL: https://login.case.edu/cas/serviceValidate (CAS protocol version 2)
Running Version: 2.0
CAS Protocol Versions Supported: 1 and 2
XML Template Returned:

 
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>abc12</cas:user>
    <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</cas:proxyGrantingTicket>
  </cas:authenticationSuccess>
</cas:serviceResponse>

If one the following clients does not work or does not apply to you, you may wish to create your own CAS client. This is relatively simple because CAS operates over HTTP and the protocol is straightforward. Consulting the CAS protocol is necessary to properly design a client.

[edit] Apache

Apache must be compiled with APache eXtenSion tool (APXS) to compile and install the mod_auth_cas object as a dynamically shared object (DSO). The instructions for setting the module up can be found here.

The following example configuration settings should work:

 
LoadModule auth_cas_module /usr/lib/apache2/modules/mod_auth_cas.so
CASLoginURL https://login.case.edu/cas/login
CASValidateURL https://login.case.edu/cas/serviceValidate
CASCertificatePath /path/to/ca-certificate.crt
#CASDebug On
CASCookiePath /path/to/cas/cookie/
<Directory "/cas-protected/">
        AuthType CAS
        AuthName "CAS"
        require valid-user
</Directory>

The CasTrustedCerts directive can point to a file containing the public certificate(s) of the Certificate Authority for the CAS server. Here is Case's certicate:

[edit] PHP

You can use phpCAS, a CAS PHP library to perform CAS authentication within your PHP applications.

Case Referrers

Blog Entries

Jeremy Smith's blog: OpenID Server Integrated with CAS (147 referral)
Jeremy Smith's blog: CAS Sucks! (131 referral)
Jeremy Smith's blog: Zero Sign On (68 referral)
Jeremy Smith's blog: Using "Google Apps for Education" at Case Western (27 referral)
Simple CAS 1.0 Authentication for Django - brian's blog (662 referral)
Gregory Szorc's blog - Case Single Sign-On Service Upgraded (141 referral)
Gregory Szorc's blog - Thoughts on Establishing a Wiki Farm (25 referral)
The Web server upgrade happens May 19, 2008. Are you ready?: Web Development Blog: Creative Services: Marketing and Communications: Case Western Reserve University (17 referral)

Other Sites

http://start.case.edu/ (17 referral)
http://filer.case.edu/aah16/public/CAS.php.txt (1 referral)

This page has been accessed 266,165 times.
This page was last modified 13:56, December 16, 2011 by Jeremy Smith.
About | Disclaimers

Case Wiki

Navigation

Search

Toolbox