Securing Your New CAS Server

The default CAS instances ships in a pretty open state for two main reasons:

1. Historically, the Yale CAS instance was an open system
2. In order to make demonstrations quick and simple, the default WAR requires minimal (i.e. no) customization to integrate.

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.

<bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
    p:cookieSecure="false"
    p:cookieMaxAge="-1"
    p:cookieName="CASTGC"
    p:cookiePath="/cas" />

See the attached presentation, SSL Considerations for CAS, for a thorough discussion of SSL considerations for a CAS deployment.

Service Restriction

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?

1. Open CAS Servers invite external parties to look like they're approved by you. Wouldn't being able to authenticate YOUR users make it look more legit? Thought so.
2. CAS Server Urls are written out to the JSP pages and used in redirects. While we XML escape them and all that fun stuff, the fact is CAS blindly will ask you to redirect or ask you to confirm redirect. (the reason is that this protocol existed before all that scary cross-site scripting fun).

What should you do to protect yourself?
The simple answer is to use the Services Management Tool. In an ideal situation, you would have each service defined in the Services Management Tool. If that's too much of a burden, at least put some generic service entries that capture common protocols you'd like to allow. We recommend controlling for at least the following:

• http
• https
• imap
• imaps

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:

• The default CAS war name
• Any Jasig logos (though hey, feel free to let us know that you're using it, and contribute back!)
• CAS version information on public-facing pages
• Overriding error pages that you may not think matter since CAS never goes down!

Secure the Server

All the usual recommendations/best practices for securing servers apply here.

Enable Throttling

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.

Enable Auditing

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.