Posted by January 30, 2013
[ 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.
Posted in Miscellaneous | Tagged: authentication, CAS, SAML 2.0, SSO | 5 Comments »
Posted by January 24, 2013
Here are some useful links to various WebSEAL concepts:
Posted in Miscellaneous | Tagged: IBM, WebSEAL | Leave a Comment »
Posted by January 23, 2013
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.
Posted in Miscellaneous | Tagged: Identify Federation, SSO | 2 Comments »
Posted by November 8, 2012
Warning: This page deals with one of the vague Policy Server flags and assumes certain level of familiarity with the dark soul of CA SiteMinder.
Is is pretty hard to understand the meaning of the
DisallowForceLogin registry key for SiteMinder Policy Server from the official documentation, even when you have plenty of time and manuals. This page pretends to summarize all that you may need to know about it, should you have to deal with this functionality some day.
History and Functionality
In a pre-R6 environment, when a user submits a password change request that contains an invalid current password, the Password Change Information screen appears with a message stating that the old password is incorrect. The user can provide the correct credential and change the password.
In R6 and R12, the Policy Server redirects the user to the login screen without the message (that is, ”forces login screen”). Enabling the
DisallowForceLogin registry key allows the old behavior in a new environment. When enabled, the Policy Server properly redirects users who have submitted a password change request that contains an invalid current password to the Password Change Information screen. This screen displays the invalid current password message. When disabled, the Policy Server redirects users to:
- The login page that does not display the invalid current password message. This redirect occurs if an
On-Auth-Reject-Redirect response is not bound to the policy configured with the user directory.
- The URL associated with the
On-Auth-Reject-Redirect response bound to the policy configured with the user directory
According to R6SP5 README, there are three cases affected by the
- Force password change or password expired.
- Self Password change.
- Optional password change.
Read the rest of this entry »
Posted in Miscellaneous | Tagged: CA, SiteMinder | Leave a Comment »
Posted by October 17, 2012
Some time ago I was asked to help in implementing an automatic test for one of the application flows. In this flow the system under test was sending emails with dynamic content to the end user, and the test had to verify the content of those emails.
The testing system had two basic requirements:
- The email address to send those emails should be unique, since several tests of this kind will run simultaneously.
- The retrieval of those emails should be as simple as possible, without any dependency on specific programming languages or libraries.
To make the long story short – the solution that we implemented consists of the ‘sendmail’ daemon with specially crafted aliases file, shell script to parse incoming email and store it in the own file by username, ‘httpd’ daemon to expose the files with emails over HTTP and a cron script to clean those files; all those based on standard RHEL 5.5 distribution. Read the rest of this entry »
Posted in Miscellaneous | Tagged: recipes, scripts | Leave a Comment »