Why you should not use CAS 3.5.1 as SAML 2.0 Identity Provider

[ Update (June 2014): Please take some time to check John’s comment below. ]

Last week I spent some time investigating SAML 2.0 support of Central Authentication Service 3.5.1 (latest version of CAS at the moment of writing). The results were disappointing.

CAS was developed by Yale University in early 2000’s and was donated to open source in 2004. It is primary used in the academic networks, but the use is now extended to the enterprise world. Initial versions of CAS were built around own custom interoperability protocol. Later it was extended to support more protocols – both standard (such as SAML 1.1, OAuth, OpenID) and custom (REST API).

The skeleton for SAML 2.0 support was implemented around 2003. The implementation was driven by the need to integrate CAS with Google Apps for Education even before SAML 2.0 was finalized as a standard in 2005. As you may guess, this implementation is not fully compatible with the approved standard. Unfortunately, it did not change a lot during those ten years. The relevant documentation page says “SAML 2.0”, yet mentions the fact that it is actually intended for Google Accounts in the big red warning at the top. The supporting code is more conscious and presents itself as “GoogleAccountsService”.

But even if you don’t really care about spec compatibility, SAML 2.0 implementation of CAS is extremely limited and is not fully secure.

First, CAS implementation does not support SAML 2.0 metadata. Besides the inconvenience of manual configuration on SP side, it has serious implications on the IdP itself. CAS will not maintain the list of trusted SPs – it will be glad to work with any SP, including  malicious ones, and will not verify validity of signed authentication requests. Actually, the whole request content besides the request ID (which must be returned in the resulting assertion) and “AssertionConsumerServiceURL” attibute (see below) is simply ignored.

As another implication of missing metadata notion, CAS will not have the pre-configured return URL for each SP and will rely on “AssertionConsumerServiceURL” request attribute. This attribute is defined as optional in SAML 2.0 specification, and some SP implementations do not provide it. Obviously, CAS will fail (in the ugly way – with NullPointerException) if this attribute is missing and will not be able to continue the flow if it does not contain valid URL. And if all this is not enough, just think about invalidated redirects

The content of the resulting response is also far from being perfect. It is built from a fixed template, with only few values replaced. Among hard-coded values are assertion issuer (sic!), authentication method and some dates. Even the computed values are mostly not configurable – for example, the assertion is always valid for 1 year. Authentication attributes that are required by some service providers are not supported also.

Bottom line:
If you are looking for enterprise-grade software to be your SAML 2.0 Identity Provider, CAS 3.5.1 is not for you.

5 thoughts on “Why you should not use CAS 3.5.1 as SAML 2.0 Identity Provider

  1. CAS will not maintain the list of trusted SPs – it will be glad to work with any SP, including malicious ones, and will not verify validity of signed authentication requests.

    CAS still utilizes its service registry and will not authenticate “SAML 2.0” services if the “AssertionConsumerServiceURL” is not listed in th registry… unless you are running in a whitelisted mode which has never been recommended for the security concerned.

    If you want the full power of SAML 2 and want/need CAS as well check out https://github.com/Unicon/shib-cas-authn2 which can integrate Shibboleth IdP and CAS. Then you get the best of both worlds.

    1. Hi John,

      This article was written 1.5 years ago, when CAS 3.5.1 was the latest available version. Now, when I’m looking on the reworked cas-server-support-saml module, I see that it contains SamlService along with GoogleAccountsService that I mentioned above. This class exists in 3.5.x branch also, but for some reason I missed it at the moment of writing (my guess it was not properly covered by the documentation). Unfortunately, I don’t have enough time to fully re-investigate the SAML 2.0 use case based on what I’ve just found.

      Anyway, thank you for pointing this out. I’ll update the article to mention your comment.

      Regards,
      Anton.

Leave a Reply