Recently I have been involved, at varying levels, in a number of projects centred around federation and primarily federated authentication. Whilst most of my work in the past has been working with the SAML specification, one of the recent projects focused around Shibboleth.
There are a couple of observations I have made when speaking to people about federation.
1. Usually, during client meetings there are several comments about how the solution has to be “Shibboleth compliant” or “SAML compliant”. However, when you dig down a bit further, you usually find that the person dictating this compliance doesn’t fully understand what they are asking for or what it means. For example, when discussing Shibboleth, the discussion moved round to talk about how it uses SAML as its underlying protocol, I asked the client what specific functionality of Shibboleth above and beyond what SAML could give them did they require. The response was very limited. (Note: I’m not particularly picking on Shibboleth here. It just happens to be a recent example). When people ask for SAML compliance, what exactly do they require? Do they plan on using every piece of the spec in its entirety, e.g. SSO, SLO, IdP Discovery etc? Are they planning on using all the bindings, e.g. Artifact, SOAP, POST, PAOS etc. For many companies, it seems to me that compliance with an open standard is sometimes just a tick in the box of an RFI/RFP rather than fully understanding what they are going to use the spec for and what benefits they will gain from its use. For example, does it matter whether a solution (thinking of no particular vendor here) supports the SAML ECP profile. Is this something the client will use in the specific project you are talking to them about.
I think it is important that people who are looking at using federation technologies understand not only what it can do, but also, what options are available within the standards for achieving the end result (including which standards to use). This also includes having an understanding of what the spec doesn’t give you (e.g. how a user authenticates to retrieve their SAML assertion). Whilst this education is the job of the relevant vendors and consultants within the industry, it is also the responsibility of the client to gain that base knowledge.
2. The second observation I has seen is the limited deployments of federated technologies. As I said above, my most recent projects have both been around federation. The plan for my clients was to minimise local user management and benefit from the SSO that you can gain through federation (fairly standard stuff). However, in both cases, when it came down to detailed discussions about the federated partners, it is surprising how many partners are just not in a position to be able to offer support for federated authentication. One particular client was looking at a system designed for approx 300,000 users. They had a local user store to account for a few ‘exceptional’ users who could not authenticate using federated technology (circa 5000 users). However, during detailed design, the number of local users rose drastically to approx 150,000 since several of the federation partners were not ready. This is not unique.
Whilst more and more people are looking at using federation in their business, I believe we are very much still at a stage of putting the technology in place and have the clients build the frameworks to support federation. That way, clients can start with a fairly central repository of users, but, over time, as business partners become ‘federation enabled’, the users can be migrated over to the external partners. Its all about flexibilty within the framework and within the architecture and not expecting that all of your Identity Providers and Service Providers will be ready to offer a full federated service from day one.