Skip to Content

Table of Contents

Where can I find a walkthrough of Proxy CAS?

At the ProxyCasWalkthrough.

Why was the LoginTicket added?

The LoginTicket was added to prevent the replaying of credentials by browsers that do not behave correctly. Picture the following situation:

User logs into an application via CAS at a kiosk.

After some browsing, the user logs out of CAS but neglects to close the browser window. The next person to use the machine clicks the "Back" button a bunch of times until the browser asks to "repost the form data". Choosing "yes" reposts the user's primary credentials (username and password) to CAS.

Safari takes it one step further by reposting the credentials to the application the user is trying to access not CAS! This of course is a separate bug which the LoginTicket cannot fix, but something to be aware of. We fixed this by not automatically bouncing the user to CAS if the user is connecting with Safari. They will see a screen that says they're logged in, and they'll have to click through to get to the application.

LoginTickets are not secrets-anyone can request one if they want. So if your login page lives in a separate webapp, one solution would be to write a simple JSP that requests a login ticket. Your login page can then contact that JSP to grab a ticket and include it in its login form.

Where can I get the ESUP-Portail quick-start release of CAS Server (with the CasGenericHandler plugin thrown in!)

Where can I get the Campus Crusade for Christ CAS server distribution, which supports Single Sign Off?

Where can I find good threads from the CAS Mailman list about practical SSL certificate issues?

Try this January 2004 thread: or this

This march 2004 thread was pretty good too:

How do I configure Tomcat to use SSL?

How do I use a self-signed certificate?

Trusting the Self-Signed Certificate DummyTrustManager for development

Joakim Recht suggested on the CAS list that in development you can avoid the need to install your self-signed CAS server certificate on your CAS clients (and your CAS client certificate on your CAS server when the clients need to be securely accessed for CAS to give them Proxy Tickets) by using the DummyTrustManager from here.

This accepts all certificates, including self-signed. This would be neither secure nor appropriate in production, but it may be just the thing to get off the ground in development.

To use the DummyTrustManager, put the files and into src/edu/yale/its/tp/cas/util and add ((HttpsURLConnection)uc).setSSLSocketFactory(new DummySSLSocketFactory()); to just after URLConnection uc = u.openConnection();.

Where can I learn more about the keytool?

Does CAS use SAML? What's the deal with CAS and Shibboleth?

CAS does not currently use SAML. There is an intent to introduce an advanced CAS protocol in the future which will use SAML to expose a richer model of the authentication. Some applications will benefit from this, while some applications will continue to find the current String-username protocol sufficient. The CAS 3.0 server implementation is sufficiently flexible that you can extend the CAS protocol, detecting ticket validation requests for SAML, and returning a SAML response. While this is not currently something that CAS does out of the box, it is quite feasible as a local modification. (If you do this, we'd really really like to hear about it and would appreciate your sharing your code. More generally, if you need this, please speak up on the cas@ email list to see what collaboration opportunities there may be.)

CAS does not use and is not formally related to Shibboleth. Whereas CAS provides single-institution SSO, Shibboleth provides cross-domain federated authentication. Additional power at the cost of additional complexity.

When implementing Shibboleth, you need to provide some kind of institution-local authentication mechanism in your Handle Server. One plausible way to implement this is to front your Handle Server with CAS authentication. By doing this users authenticating through your Handle Server will have both an instiution-local CAS SSO session (useful for institution-local applications which can take advantage of the CAS client libraries) and an Shibboleth Handle-Server-mediated SSO session across the federation. Under this approach you can take advantage of CAS Server 3's flexibility and power for implementing your particular authentication user experience.

Another, perhaps more controversial, but nonetheless plausible role for CAS in your Shibboleth implementation is as an intermediary between Shibboleth and your application. While Shibboleth and SAML provide a rich body of information about the authentication, you may wish to implement a single point within your institution that interprets this authentication information, attribute assertions, etc., and applies institution-local policy, translating from the complex and rich world of Shibboleth down to the much simpler protocol of CAS. You could use a CAS instance to serve as this intermediary, receiving and interpretting Shibboleth authentication and exposinng the CAS abstraction. Applicatinos in your institution could then support cross-federation authentication while continuing to use the CAS client libraries and the CAS protocol.

This issue has been discussed previously on the cas email lists (e.g.) and the archives are worth perusing on this subject. Howard Gilbert has written in some detail on this subject.