Securing Your New CAS Server
The default CAS instances ships in a pretty open state for two main reasons:
However, that doesn't mean you should or want to leave it in that state. This page walks through some of the things you may wish to consider.
SSL || !SSL
On the mailing lists we often get questions on why SSO does not seem to be working. By default, CAS only sends the single sign on cookie (CASTGC) over secure connections; in other words it is not sent over a plain HTTP channel. Without the SSO cookie CAS requires reauthentication on every request for a service ticket, which explains the lack of SSO behavior. Although it is possible to disable this behavior, we strongly encourage accessing CAS and application entry points over SSL/TLS.
The following configuration excerpt demonstrates how to enable sending the CAS SSO cookie over plain HTTP. This is strongly discouraged except for development and testing.
See the attached presentation, SSL Considerations for CAS, for a thorough discussion of SSL considerations for a CAS deployment.
By default, CAS ships without any restrictions on which services it can use. In fact the CAS protocol does not define what a service can look like! Sounds nice, right? You can use string identifiers, made-up protocols, and other fun stuff. Handy for proxying, RESTful APIs, and more. However, it might not be good with browser interaction. Why not, you ask?
What should you do to protect yourself?
Carefully Control Your JSP
The CAS Server strives to demonstrate best practices and good usability. We, however, don't always get it perfect, or right, and we continually evolve these pages. Therefore, while we recommend our pages as a starting point, your security team, and yourself, should still check any pages you create or modify, or extend, against common security risks.
A great example of this is the url param on the logout page. This feature was added in CAS2, and has been carried forward against all versions of CAS. The value is XML-escaped before being presented on the page, but it still exhibits the same risks as service urls. If you're not using this feature, its highly recommended it be removed.
Other features should be evaluated also (i.e. we set autocomplete=false on forms by default). If you have any recommendations for better out of the box examples, be sure to share them with the CAS Community.
Security Through Obfuscation
While we all know that obfuscation isn't really a perfect security technique, it sure helps out a lot. Just like its recommended that HTTP servers not announce their type/version, you may want to hide some of the obvious facts that you're using CAS, including:
Secure the Server
All the usual recommendations/best practices for securing servers apply here.
CAS supports a combination of throttling authentication requests via IP address and/or username. Deployers are encouraged to use one of them. Single-machine CAS instances can use the in-memory support which is extremely fast. Multi-machine CAS instances MUST use one of the ones that integrates with the auditing framework, which pulls statistics from the auditing database.
Throttling CAS authentications means that when a single username or IP address reaches a threshold of failures within a certain period of time, they are prevented from attempting additional authentications until they are below the threshold (additional failures may then place them above the threshold). This can ultimately reduce load on the backend authentication mechanism, and on the front-end CAS servers.
While auditing does not make the system more secure, it can provide a forensic trace of where a compromised account was used, as well as when, and potentially what information was accessed. CAS uses the Inspektr library for its auditing framework, and the framework provides an extensive APIs for logging the details important to you and in the location you prefer. Most deployers either log the audit information to local files via the commons Logging/SLF4J integration and then pull it into a tool like Splunk, or log it directly into the database.
Reduce Ticket Validity Lengths
The CAS protocol specifies the lengths of time that it recommends a ticket be valid for. For service tickets, these times are often much longer than necessary for it to be processed. The extra length of time means that one can pass a URL with ticket to a friend and have them log in as you (see bearer tokens). There are ways to mitigate this including UI enhancements to clients. One other way is to reduce the ticket validity time to a much shorter time, say 5 seconds.