After struggling some time with CAS, I finally ended up working with SimpleSAMLphp package. I can recommend it as really simple yet powerful software. The package contains ready-to-use SAML 2.0 IdP site and provides PHP API to integrate your application with SAML 2.0 Service Provider functionality. The handling of the actual authentication process is delegated to a rich set of authentication modules, and in case no build-in module fits your needs – you have all the power to implement your own module in hours.
[ 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.
If you are looking for enterprise-grade software to be your SAML 2.0 Identity Provider, CAS 3.5.1 is not for you.
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.