A few days ago I wrote a post around federation and how I was surprised it wasn’t simpler to configure.
In response to this, “Curious” posted a comment directing me to a post by James Mcgovern where he talks about why federation has been slow to be adopted and how this could be partly the fault of the vendors and the industry analysts. Whilst I agree with the message that James is trying to convey, there is one particular point he writes that I don’t necessarily agree with.
“I wonder if the CTOs of these companies have ever considered that if they expect to sell solutions to federated identity that part of the purchase requirement may be the need to federate with someone else that already has the software?”
Whilst I believe that it is normally a major benefit if your trusted partner(s) already has a federation solution in place, I don’t think it is a necessity. There is no reason why the deployment of a federated solution couldn’t encompass both ends of the partnership at the same time. I do agree, however, that it is simpler and usually quicker from a design and deployment perspective, if indeed, the trusted partner already has the technology in place and is using it already.
However, it can also introduce extra challenges when trying to integrate with existing deployments. Lets say, for example, that you want to role out a new federation platform based on SAML 2.0 (see why the Danish public sector chose SAML 2.0 over other standards here). Since SAML isn’t backwardly compatible between versions, this poses a problem when trying to partner with a service provider who only supports SAML 1.0. Here you have two options:
1) Pick a product that supports both versions of the standard and then configure different protocols for different partnerships.
2) Utilise a further standard outside of SAML to provide the ‘glue’ between the two versions of the protocol and handle the token conversion (e.g. WS-Trust)
Had the partner not had an existing SAML deployment already, it would have potentially been possible to deploy and utilise a single version of SAML (i.e. 2.0) and to help guide the partner to ‘federation enable’ their software. This could be through a full access management type product (e.g. Tivoli, eTrust, Fusion etc) or through a lightweight engine (e.g. PingFederate). Obviously, there are a number of factors that would help make this decision which I won’t go into now. Adopting a single version of the standard may seem less flexible but if there are no reasons for using multiple different protocols or versions, why complicate the architecture.
Therefore, to summarise, I think there are advantages and disadvantages to integrating with partners who already have federation enabled infrastructures. In some cases it can be a major bonus and in others it can add additional (but not insummountable) deployment challenges.