Frequently Asked Questions

Q: Why should I use the Services Management Tool? It seems like EFFORT to set up and deploy.

Answer: By default, CAS3 ships out of the box with the Services Management Tool disabled. Why? Well the first is purely so that the user experience between downloading CAS2 and download CAS3 is the same. I.e. by default its an open system. The second reason is that for demonstration purposes, its just easier if you don't need to fiddle with that tool.

However, just because we've disabled it by default for historical and demonstration purposes doesn't mean that you shouldn't use it! We actually recommend that you have it enabled (in fact, here at Rutgers, we had a custom whitelist implementation before the Services Management tool existed). The benefit of using the Services Management tool is that it allows you to lock down CAS. It gives the CAS administrator the ability to control who can use CAS, versus it being open to the world. Being open to the world allows third-party, possibly off-site, clients to utilize CAS without your knowledge (unless you actively look at your Apache logs). This can create an unanticipated load on the servers (especially if its being used for some form of voting or contest) and also implies an association with the University that may not exist. One would assume that anything that utilizes your CAS server has some form of legitimate association with the University, however loose that association may be. CAS being an open relay allows clients with a non-legitimate association to piggyback on that assumption.

Enabling the Services Management tool provides you with more control over the technical aspects of your CAS server as well as protecting the brand image of your institution.

As a side effect of using the Services Management tool, you have the ability to control which attributes, if any, are returned to client applications (assuming you're using a modified CAS2 protocol or SAML 1.1).

NOTE: The promiscuous availability of CAS to unintended parties will leak information about users' network identifier (login ID), which can inform malicious individuals of necessary information used to break into your system.

Why should I require CAS to run over HTTPS, or the client applications to run over HTTPS?

Answer: Its most likely self-evident why CAS would need to be run over HTTPS: it handles the passwords! You should never pass passwords in the clear! You've instantly decreased the LoA of any user who utilizes CAS over HTTP.

Its less evident why CAS clients should need HTTPS because after all, they don't handle the password. However, CAS clients handle the token which after validation identifies the user. If HTTPS is not used, the entire request is susceptible to a man-in-the-middle attack in which the token could be stolen and used by a nefarious person. Using HTTPS encrypts the entire request preventing the token from being stolen. We always recommend that you use HTTPS though we recognize that in some instances it may be overkill because of the service involved and the cost of the commercial certificate (at which point we recommend a non-commercial certificate).

The only instances where its really not necessary to use HTTPS are local development and demonstration instances where live passwords are not being used. Once a live password is used, or production resources are involved, HTTPS should be used.

Which TicketRegistry should I use?

Answer: Each TicketRegistry has its pros and cons, and depending on your situation, you'll choose different options.

DefaultTicketRegistry - Choose this TicketRegistry if you have pretty much the "stock" CAS server. One server, short-lived tickets, etc. You'd also choose this one if you were using Terracotta.

JpaTicketRegistry - Choose this TicketRegistry if you're storing tickets for longer periods of time (i.e. a month) or if you need a distributed ticket store and your database is built out.

BerkeleyDbRegistry - This one is used if you have one server and you plan on storing tickets for a longer period of time (i.e. a month).

MemcachedTicketRegistry - Choose this TicketRegistry if you have multiple CAS servers and you need them to share the tickets in a high-speed environment. There are some limitations to this in that all servers must be aware of each other (i.e. they must be configured).

JBossCacheTicketRegistry - You can also use this one if you have multiple CAS servers and you need them to share tickets. Its trickier to set up but gives you more options since it uses JGroups underneath.

Note, that for any ticket registry that shares state across the network, proper care should be taken to ensure that the transmission of that data is secure. See the section in the User Manual on Clustering Considerations.

Why would I want the CAS Server to be Highly Available? And How do I do it?

Answer: You want it highly available because you've convinced everyone they should use CAS! And if CAS goes down, no one can log into anything! How do you do it? Well that's a much more complicated question. First, read Adam and my presentation on High Availability CAS. It contains a lot of information.

Now that you've done that, consider the investment you want to make in CAS to make it highly available. For example, at Rutgers, we're taking a more general approach to making as many applications as possible highly available. CAS happens to be one of the one's we're doing first. So we have or will have redundant content switches in at least two machine rooms, two CAS servers in each machine room, along with two servers in each machine room to handle memcached. We've worked with our networking teams to ensure that the routers can handle that CAS may be available in two places. We're also working to ensure that the communication between the servers is secure, even across machine rooms.

If you're not as concerned about high availability as we are, you may be able to get away with redundant servers and load balancing using Apache, etc. Again, the presentation has more details on that.

A final consideration would be disaster recovery which would mean being able to bring up CAS at an off-site location.