Skip to Content

Table of Contents


How do you tell the CAS server whether you want a plain text (CAS 1.0) or XML (CAS 2.0) response?

You choose by making the request either to the '.../validate' or '.../serviceValidate' URL. The older protocol supports only the CAS 1.0 functionality, which is left around as the legacy '.../validate' URL.


Where can I get information about the ESUP-Portail CAS Generic Handler plugin?

Visit the CasGenericHandler page for more information.


Why do I have to configure the CASFilter explicitly with the name of the protected server or service?

The README of the Java Servlet filter states that it would be more secure to specify the server name edu.yale.its.tp.cas.client.filter.serverName for the protected service explicitly than determining it automatically.

What exactly are the security issues that have been considered here?

The only way to determine the hostname "automatically" is to rely on the HTTP request's "Host" header, which is under the control of the client. Service X could receive an otherwise legitimate service ticket for service X, and it could then pass this service ticket onto client Y but pass the HTTP host header "Host: X". Service Y will then validate the ticket against CAS reporting that it's service X; CAS will determine that the ticket matches X and respond with a positive authentication. This allows an illicit proxy from service X to service Y. (Note that the end user would need to visit service X for the exploit to work; service X wouldn't be able to compromise service Y with respect to artibrary users' authentications.)

The clients (not just the filter) address this problem by requiring either a statically configured hostname or a statically configured service URL. There are other ways around this exploit (e.g., it won't work on a web server configured to respond only to one particular hostname, but this is atypical), but explicit configuration in the clients was deemed to be most likely to lead to a secure result.

This is explained in more detail in the "HISTORY" file that comes with the CAS client distribution. Note that an appropriately written client gives the user no choice; you say the README says "it would be more secure" to set the service URL manually, but with respect to end users of the filter, this is a requirement, not a recommendation. (The filter will fail to run unless you configure a hostname or a URL.)


How do I use the authorizedProxy parameter to CASFilter?

The authorizedProxy must be the url to which CAS sends the proxy granting ticket. CAS actually validates the certificate at this url. The applicaton in the middle tier uses ProxyTicketReceptor servlet to receive the proxy granting ticket. This is the url you supply to the CASFilter as an authorized proxy to instruct it to accept authentication proxied using proxy tickets derived from ProxyGrantingTickets sent to that authorizedProxy URL by CAS.

New with casclient 2.0.11, you can specify multiple authorized proxies as a whitespace-delimited list.


How does the ProxyTicketReceptor work? Does it leak memory?

It's probably worth describing this in a bit of detail. In terms strictly of CAS's protocols, the PGT IOU is used exactly once by a "proxy" to retrieve a "proxy granting ticket" (PGT). As far as the CAS server is concerned, the IOU has only this function (which in turn serves to authenticate the proxy).

In the ProxyTicketReceptor code -one mechanism provided by the client library to make it easier to set up a CAS proxy- the IOU is used also as a convenient handle that lets code calling ProxyTicketReceptor.getProxyTicket() retrieve a proxy ticket. In other words, you need *some* way to identify the PGT that you want to use when you call getProxyTicket(), and using the PGT itself might be less secure in a portal environment in which you don't trust individual channels (i.e., callers of getProxyTicket()) with sensitive information (such as a plaintext PGT). The ProxyTicketReceptor could easily generate an arbitrary handle and make sure clients get this handle, but the IOU happened to serve this function conveniently, so there was no reason to bother with a separate handle.

Thus, while the IOU is "used" only once as far as CAS is concerned, it continues to be used by ProxyTicketReceptor and the code that calls it. So an arbitrary fixed timeout wouldn't be appropriate; the PGT might outlast this timeout. However, since the PGT expires after a period of disuse, an inactivity timeout in ProxyTicketReceptor might be appropriate, as might the weak reference you suggest. (I haven't thought the latter through -perhaps uPortal persists data in ways that would cause a weak reference not to work as you expect -but it makes sense on the surface, for you only want to keep the data in the ProxyTicketReceptor's Map as long as someone else has a reference to it. But, for instance, in a distributed environment involving multiple JVMs, an inactivity timeout might be easier.)

Another alternative would be to add a clean-up method to ProxyTicketReceptor called by code that invalidates a user's session or otherwise logs a user out.

Note that the data in the Map is so small, in practical terms, that it's unlikely ever to grow to a point that's problematic.


Where can I get information about a library for making WebObjects applications clients of CAS authentication? (in French)

http://www.univ-lr.fr/apps/support/common/criwebapp/

How can uPortal use the authentication proxying features of CAS?

See http://web.princeton.edu/sites/isapps/jasig/2003summerWestminster/presen... . Use Powerpoint and note the interactions between CAS and the portal animated in slide #6.

We use proxy authentication with the portal. For example, a channel from our LMS requires user authentication via proxy. There are several key components. The CAS security provider which you probably already understand. In addition there is a CAS proxy ticket acceptor servlet which comes with the CAS client java library. This servlet is also deployed in the portal context. At the time of authentication, the security provider validates the user with CAS. CAS sends a proxy granting ticket to the servlet (must be over ssl) and a token to the security provider along with the validation results.

Later a channel wants access to a backend protected by CAS. The channel makes a call to a method in the CAS security provider which returns a proxy ticket. It then attaches that to the connection to the back end. To validate the ticket, the back end calls CAS proxy authentication service and gets back: y/n for success or failure netid in case of success AND the ssl url of intervening proxies (the url in our case of the CAS proxy ticket acceptor servlet). The application decides whether the url of the proxy is acceptable and if so responds with the requested data. The servlet filter provided in the CAS client package contains code to support the proxy authentication so you can use that or use it as an example.


What is Spring? What is the Acegi Security System for Spring? Does Acegi support / integrate with CAS? (Hint: yes, it does!) Are there any frameworks that help me build enterprise (data-centric) applications which use CAS?

Yes. The Spring Framework is a popular, layered Java/J2EE application framework, with features including powerful JavaBeans-based configuration management; generic abstraction for transaction management; JDBC abstraction layer; integration with Hibernate, JDO and iBATIS SQL Maps; rich AOP functionality; and a flexible web MVC framework. Spring provides packages that assist in building complex web applications, web services endpoints, and Swing-based rich clients.

The Acegi Security System for Spring provides a wide range of security services for Spring-based applications, including method interception, web request interception and redirection, and rich client (Swing) integration. Acegi Security maintains packages which provide full integration with CAS. The packages also allow (but do not require) Acegi Security's AuthenticationProviders - which include JDBC, in-memory and JAAS wrapper providers - to be used as CAS PasswordHandlers, easing migration from stand-alone Acegi Security applications to a CAS-managed environment.


Where can I get information about phpCAS, a PHP client library for CAS?

http://esup-phpcas.sourceforge.net/

Where can I get PerlCAS, a CAS 2.0 Perl library?

http://sourcesup.cru.fr/perlcas/

Where can I get Powerpoint presentations about CAS?

CAS presentations are now uploaded to our Slideshare account.

Where can I get whitepapers about CAS?

See the CAS in Print  page.

Who uses CAS?

Visit our deployers page to find out.

How can I join the CAS discussion list?

See the CAS mailing lists  page.

Where can I find French-speaking CAS email lists?

You can find them here: http://listes.esup-portail.org/wws/lists/cas

But I hope you will join our English-speaking CAS discussion list as well.


What applications are already distributed supporting CAS?

http://www.yale.edu/tp/cas/faq/casifiedApplications/

What kinds of resources are likely to be required to install and support a deployment of the Central Authentication Service at my institution?

Please see our list of deployers who have listed their resources .


How might I CASify Oracle Portal?

See the related Wiki page .


How might I CASify Oracle 11i applications?

Visit our file gallery for a solutions document that may help.


I'm familiar with setting up self-signed certs for Tomcat, but I'm having trouble with mod_cas and pam_cas. They don't like the .pem file I'm providing (X509_verify_cert says it's a bad cert). Is it possible to use a self-signed cert with mod_cas and if so, how do I generate the .pem file it seems to be looking for?

Inside /etc/httpd/conf run "make testcert". Then copy the "ssl.crt/server.crt" to where ever you need it. It is in PEM format.


Why does mod_cas double-submit the validate request?

We don't know yet, but we'd sure like to post an answer here!

K.C. Baltz writes on the CAS list:

I'm trying to deploy mod_cas with Apache 2.0.50 and having a problem. I'm being correctly redirected to the CAS Login page, but from there, I get into an infinite series of redirects. Looking into the apache
access logs on my CAS server box, I always see two requests like this:

67.29.152.125 - - 27/Sep/2004:12:51:00 -0400 "GET
/cas/validate?ticket=ST-1-6mfLnFi9alsXTPfDiEPu&service=http://myservice.myhost.foo/icons/pdf.gif
HTTP/1.0" 200 35

67.29.152.125 - - 27/Sep/2004:12:51:00 -0400 "GET
/cas/validate?ticket=ST-1-6mfLnFi9alsXTPfDiEPu&service=http://myservice.myhost.foo/icons/pdf.gif
HTTP/1.0" 200 4

(I've CAS-ified the /icons directory as a test. Also, I changed my service name in the above listing to protect the innocent :)).

I think the problem is that the ticket is correctly verified the first time, but the second request is (correctly) not valid because the ticket is used up and for some reason that's the one the browser pays attention to, so the redirect is issued to get a new ticket. Any thoughts on what could be causing this?

I should add that it looks like mod_cas is sending a cookie, but I don't see that cookie ever appear in my browser (I'm checking using Mozilla's cookie manager).