All:
The term "federation" has been circulating throughout the identity management (IdM) and network security markets for the past several years. It has acquired the status of a holy buzzword, promising flexible, standards-based, loosely coupled single sign-on (SSO) over Web services environments. A growing range of Web services standards--such as Security Assertion Markup Language (SAML), Liberty Alliance Identity Federation Framework (ID-FF), and WS-Security--have sprung up to realize the federation dream. In the process, the concept has usurped much of the industry mindspace formerly enjoyed by public key infrastructure (PKI) and trust infrastructure, though federation environments rely on all of that infrastructure.
However, like all buzzwords that become too popular, "federation" is starting to feel a bit shopworn.
For one thing, the industry has never converged on a consensus definition. One of the most common definitions is that federation "makes identities portable across autonomous domains." That definition has never felt right to me, because it's clearly contradicted by the dominant federation approach: interchange of identity assertions between identity providers (IDPs) and service providers (SPs)--such as under various SAML and Liberty ID-FF implementation profiles. SAML and Liberty do not make "identities portable across domains." Rather, they do the exact opposite. Identities stay put in the IDP domains in which they were registered. Identities are not synchronized or transfered to other domains. Instead, IDPs authenticate logins locally, and simply transfer vouchers for those logins (which SAML calls "authentication assertions") to relying (SP) domains. What identity federation is really about, then, is not to make identities portable across autonomous domains. Rather, identity federation simply makes assertions about identity-related events (e.g., logins) portable across autonomous domains. That's an important distinction. One of the great advantages of federated identity (over, say, meta-directories) is that domains can prevent disclosure of identity information to other domains.
Another problem is that the industry has applied the concept of federation too narrowly. Federation can and should be applied to more than just identity management. And federation can and should leverage the core Web services middleware environment more thoroughly. A more general definition of federation would be as follows: “a governance framework within which autonomous domains honor each other’s decisions and accept each other’s assertions, subject to their respective local policies.”
Looked at that way, we can define federation models in the various tiers of a distributed fabric:
* Presentation tier: presentation servers in different domains federate domain-spanning user sessions
* Business-logic tier: integration brokers in different domains federate domain-spanning business processes
* Data tier: data repositories in different domains federate domain-spanning information-integration scenarios
* Identity/security tier: IdM and security systems in different domains federate domain-spanning account provisioning, SSO, role-based access control, and other scenarios
* Management tier: management systems in different domains federated domain-spanning fault, availability, reliability, performance, and QoS scenarios
Fundamentally, federation environments enable arms-length interoperability among domains through publish-subscribe relationships. Domains choose to publish assertions out to other domains, and to subscribe to assertions issued by other domains. The term “assertion” here should be interpreted more broadly than simply “SAML assertion” or “identity assertion.” An assertion, understood broadly, is any statement about some event, object, or state controlled, owned, or managed by the asserting domain (such as session state, in the presentation tier; orchestration process status, in the business-logic tier; create, update, and delete operations, in the data tier; user logins, in the identity/security tier; and system faults, in the management tier).
To enable federation as a broader, standards-based infrastructure, all of these tiers will need to leverage emerging WS-* for topic-based publish/subscribe (WS-Notification), event notification (WS-Eventing), and reliable messaging (WS-ReliableMessaging).
For starters, I’d like to recommend that the IdM industry put this matter on the roadmap for SAML 3.0 (or whatever it will be called), which, presumably, will converge SAML 2.0 (itself still in the works) and WS-Federation (which is in a state of suspended development at this time). SAML 3.0 (or WS-SAML, or WS-Federation, or whatever it may ultimately be called) should include an implementation profile that describes how SAML IDPs and SPs can leverage WS-Notification et al. within their “inter-site transfer service” (complementing the browser/artifact, browser/post, and other existing profiles).
Over the next 3-5 years, these WS-* standards will form the basis for the enterprise service bus (ESB), enabling robust interoperability traditionally associated with message-oriented middleware. Federation across all distributed tiers will rely critically on these standards. The IdM industry should take the lead, recognize that inevitable trend, and begin to implement them in their federation standards.
Jim
