CAS Single Sign-On at CWRU - KBA

Central Authentication Service (CAS) provides a standard format in which to supply credentials used by individual services and protocols to authorize access to secure resources. Users may login using CAS at login.case.edu.

After authenticating, a user can be programmatically signed in to any application that uses the service for a period of up to 8 hours.

Authentication services are operated by University Technology. If you have additional questions or are having a problem using single-sign on, contact the Service Desk. Or, for questions regarding concerning implementing or configuring CAS, contact single sign-on administration by email.

P: 216.368.HELP
sso-admin@case.edu

Crawford Building,
10900 Euclid Avenue 
Cleveland, OH 44106-4932


FAQ

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

CAS integrates with password policy requirements. You may not log in to CAS if your password is expired. Instead, you will be provided a link to change your password.


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 signed in to other sites. This cookie is set to expire at the end of your browser session.

It is possible to log out of CAS by visiting https://login.case.edu/cas/logout. However, this is not a secure. Closing your browser is the easiest way to guarantee that another user does not access services using your identity.

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 but not authorization. Individual services must determine whether a user is allowed to access them.


How do I obtain the user’s name, status, etc.?

CAS does not provide information about users. This information is contained within the university LDAP server.

However, it is possible for services to query the LDAP server for information about authenticated users in order to control and customize service behavior. Examples include:

  • Displaying a user’s name,
  • Filtering content based on user role (e.g., student, staff, faculty, etc),
  • Filtering content based on student grade level

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.


How CAS Works

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.


Detailed overview

When you log into CAS at https://login.case.edu/cas/login, 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.cgivia 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.

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 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:authenticationSuccess>
</cas:serviceResponse>

Alternatively, the CAS client can query

https://login.case.edu/cas/validate?ticket=ST-3555-McPZ4NKfx6S0EhnCEkHc&amp;
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.


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


CAS Implementation Best Practices

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.

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.


Configuring Applications to Use CAS

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

Note that the above templates have been compressed to save space and formatted to make them easy to read. The XML returned by the CAS server is not guaranteed to have the exact (or any) indentation, and may contain additional blank lines. The only guarantee is that the the components as shown above will exist, and that the XML returned will be valid XML. It is strongly suggested, therefore to use either one of the CAS clients mentioned below. If you are attempting to create your own CAS client, the use of an XML parser is REQUIRED to handle the returned XML. Do NOT attempt to parse the XML according to the formatting of the templates provided above.

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.


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

Module setup instructions

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>

Certificates

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 certificate, including the root (first in the list) and intermediate certificates. In many Java-based applications the entire chain must be loaded into the Java keystore for the certificate chain to be trusted.

-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIQf3HB06ImsNKxE/PmgWdkPjANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEwMTIwNzAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
UTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UECxMISW5D
b21tb24xGzAZBgNVBAMTEkluQ29tbW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAJd8x8j+s+kgaqOkT46ONFYGs3psqhCbSGErNpBp
4zQKR6e7e96qavvrgpWPyh1/r3WmqEzaIGdhGg2GwcrBh6+sTuTeYhsvnbGYr8YB
+xdw26wUWexvPzN/ppgL5OI4r/V/hW0OdASd9ieGx5uP53EqCPQDAkBjJH1AV49U
4FR+thNIYfHezg69tvpNmLLZDY15puCqzQyRmqXfq3O7yhR4XEcpocrFup/H2mD3
/+d/8tnaoS0PSRan0wCSz4pH2U341ZVm03T5gGMAT0yEFh+z9SQfoU7e6JXWsgsJ
iyxrx1wvjGPJmctSsWJ7cwFif2Ns2Gig7mqojR8p89AYrK0CAwEAAaOCAXcwggFz
MB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBRIT1r6
L0qaXuBQ82t7VaXe9b40XTAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB
/wIBADARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMIGz
BggrBgEFBQcBAQSBpjCBozA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1
c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QucDdjMDkGCCsGAQUFBzAChi1o
dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RVVE5TR0NDQS5jcnQwJQYI
KwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEF
BQADggEBAJNmIYB0RYVLwqvOMrAp/t3f1iRbvwNqb1A+DhuzDYijW+7EpBI7Vu8G
f89/IZVWO0Ex/uGqk9KV85UNPEerylwmrT7x+Yw0bhG+9GfjAkn5pnx7ZCXdF0by
UOPjCiE6SSTNxoRlaGdosEUtR5nNnKuGKRFy3NacNkN089SXnlag/l9AWNLV1358
xY4asgRckmYOha0uBs7Io9jrFCeR3s8XMIFTtmYSrTfk9e+WXCAONumsYn0ZgYr1
kGGmSavOPN/mymTugmU5RZUWukEGAJi6DFZh5MbGhgHPZqkiKQLWPc/EKo2Z3vsJ
FJ4O0dXG14HdrSSrrAcF4h1ow3BmX9M=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGRzCCBS+gAwIBAgIRALg60ZJmT/8qmKWgMpLFRqAwDQYJKoZIhvcNAQEFBQAw
UTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UECxMISW5D
b21tb24xGzAZBgNVBAMTEkluQ29tbW9uIFNlcnZlciBDQTAeFw0xNDEwMjIwMDAw
MDBaFw0xNTEwMjIyMzU5NTlaMIHOMQswCQYDVQQGEwJVUzETMBEGA1UEERMKNDQx
MDYtNzAxOTELMAkGA1UECBMCT0gxEjAQBgNVBAcTCUNsZXZlbGFuZDEcMBoGA1UE
CRMTMTA5MDAgRXVjbGlkIEF2ZW51ZTEoMCYGA1UEChMfQ2FzZSBXZXN0ZXJuIFJl
c2VydmUgVW5pdmVyc2l0eTEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9n
eSBTZXJ2aWNlczEXMBUGA1UEAxMObG9naW4uY2FzZS5lZHUwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC690Dr9CwvXmaP3Jd32ilub3vl1eH4jpY9uYWz
HKuAzOP3BA8hkrnvNgsTuGw0UkD8zh8mGIQ7pKYiqZMUFC80iRfhz8NDD0b/BedO
omyAt5ReQTxEHaKqYPNODZ9LcSq3TzpznRxRO+nrnuZ+W5gtO2dB6Iikt9x3geNL
Qd55bd/yVbiusjgmsicbZzQN/i+S34RJWBPznare27v84n+P6YVdc43lKug3pdQH
NpmCrJWcU6cVn04v5UyP36MK7r4Ub9sOLw+IsPyAujA9PfWhKSUcduyy/AWvqoPv
vtNmwbanlH2rH1OrrqxsPgBv2f2ZcO66WSsnKVHkRfldz7EdAgMBAAGjggKaMIIC
ljAfBgNVHSMEGDAWgBRIT1r6L0qaXuBQ82t7VaXe9b40XTAdBgNVHQ4EFgQUFKu4
wRMlac3IMNJyLY1CvuInIsMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGcGA1UdIARgMF4wUgYMKwYB
BAGuIwEEAwEBMEIwQAYIKwYBBQUHAgEWNGh0dHBzOi8vd3d3LmluY29tbW9uLm9y
Zy9jZXJ0L3JlcG9zaXRvcnkvY3BzX3NzbC5wZGYwCAYGZ4EMAQICMD0GA1UdHwQ2
MDQwMqAwoC6GLGh0dHA6Ly9jcmwuaW5jb21tb24ub3JnL0luQ29tbW9uU2VydmVy
Q0EuY3JsMG8GCCsGAQUFBwEBBGMwYTA5BggrBgEFBQcwAoYtaHR0cDovL2NlcnQu
aW5jb21tb24ub3JnL0luQ29tbW9uU2VydmVyQ0EuY3J0MCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC5pbmNvbW1vbi5vcmcwgf0GA1UdEQSB9TCB8oIObG9naW4uY2Fz
ZS5lZHWCE2xvZ2luLXByb2QuY2FzZS5lZHWCE2xvZ2luLXByb2QuY3dydS5lZHWC
DmxvZ2luLmN3cnUuZWR1ghNzc29wLWNmZC0xLmNhc2UuZWR1ghNzc29wLWNmZC0x
LmN3cnUuZWR1ghNzc29wLWNmZC0yLmNhc2UuZWR1ghNzc29wLWNmZC0yLmN3cnUu
ZWR1ghNzc29wLWtzbC0xLmNhc2UuZWR1ghNzc29wLWtzbC0xLmN3cnUuZWR1ghNz
c29wLWtzbC0yLmNhc2UuZWR1ghNzc29wLWtzbC0yLmN3cnUuZWR1MA0GCSqGSIb3
DQEBBQUAA4IBAQAl2tVMq0i24zRHqOUV0EJkFF4DhSB4p0uRYQoEm1VXiiaz7LbD
A2T3i/ilvO2KiSOg6KJ1toGy/dANH7u4FjAT7Cc0N490N4Ihd8LxRCtTURIXijhC
WwxiprQiNoo12egfbB0apDVsGBoEkDed79R6Rqns1N0IrwVRw0OUHoVF8Gh3/fzr
kXfI3zYs3Y5RTJHaAxBM3YtQR1vVRNcQ1lqWH+qhcZKUmOnwJ79e5+MZ7BUStqsd
wffz5y5aEhASsWSpxjXq/7KqNjB4YKQ54y/6rOFqe/qxah3fzGle/aik85dMps0L
ne9YBzuVOH/lghrKnZc6hiFe6/Zf0qyp2Tc2
-----END CERTIFICATE-----