Among the earliest inhibitors to the adoption of federated identity management technology were the business issues with identifying suitable federation partners and negotiating agreements on things such as how liability and risk might be shared. Not the kind of thing that technical people like to see get in the way of an exciting innovation but clearly a reality. This issue led to early patterns for identity federation based on connecting loosely coupled agencies over which some common governance existed, such as departments within a government, major divisions of a global enterprise or a conglomerate composed of mergers and acquisitions.

Public, hybrid and community clouds are creating a new wave for federated identity management technologies. I don't consider that a novel contribution from my keyboard - it's been well recognized by analysts studying this space. To some degree, they are following the 'federate with a related entity' pattern described above. Some might argue that the cloud scenarios are 'federate with (a different manifestation of) yourself'.

It's not quite the same of course. The federation may technically be with some common components managed by the cloud service provider, and that may constrain choices of FSSO protocols, characteristics of the key material, content of security assertions, etc. Benefits remain with the organization choosing to move some workloads to the cloud, including the ability to integrate with sophisticated authentication infrastructure already in place on-premise, rather than replicating it in the cloud or relying only on the options offered by the cloud service provider.