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.

Deploying a Web Application from Maven Build to Remote Tomcat Container with Cargo

Several days ago I had to implement a mechanism that uploads a web application to the running instance of Tomcat. The web application was build using Maven, so the obvious choice was Maven Cargo plugin. The Cargo framework is mostly intended for integration testing, but it’s Maven plugin can do some useful things by the way, as a side effect. There are a lot of documentation on the web about Cargo in general and remote deployment to Tomcat specifically, but I was unable to find the complete example to be taken as-is. So, here it goes!
Continue reading “Deploying a Web Application from Maven Build to Remote Tomcat Container with Cargo”

Difference between SSO (Single Sign On) and Identity Federation

There is a lot of confusion on the net between SSO and Identity Federation. Both concepts may look the same to the end users, but they are different. Today many authentication products implement both, further increasing the confusion. Here I’ll try to explain the difference as I see it.

Identify Federation (sometimes referred as Federation or Federated Identity) allows the end users to use the same set of credentials to obtain access to multiple resources. This gives an advantage to the software systems that utilize Identify Federation, both from security and usability perspective – the end users do not have to maintain multiple sets of credentials. Yet, the users have to provide their credentials to each one of the participating resources. Typically Identify Federation system are based on single credentials store, but other implementation methods (for example, password synchronization) may also be used.

SSO (Single Sign On) allows the end users to provide their credentials once and obtain access to multiple resources. The key point of the concept is that the users are not prompted for their credentials anew on access to participating resources until the active session is terminated. The participating resources are typically related, but still remain independent. Specifically, each system may have own authorization system, providing system-specific roles to the end users. The practical implementation of the supporting software system remains out of scope for the concept definition.