Meanwhile, Microsoft and IBM have developed their own stack of OASIS-sanctioned standards sporting a “WS” (Web services) prefix.
The draft WS-Federation specification defines federated identity-mapping mechanisms within the larger context of WS-Security,
now in Version 1.0 and considered fundamental to the Web services protocol stack. WS-Security provides a framework for secure
messaging into which developers can plug WS specs that address specific security functions -- including the draft WS-Trust
standard, which has the quixotic mission of helping one server decide whether it can trust another enough to exchange data,
without human intervention.
Although the Liberty Alliance standards and the WS specification for federated identity overlap in some places, the two are
not incompatible. The Liberty Alliance has committed to interoperability with WS-Security, and enterprises that have deployed
Web services with WS-Security often combine it with SAML.
“There are products on the market and technologies out there to enable federation,” says Andrew Shikiar, group marketing manager
for identity and Liberty at Sun Microsystems. “Now the challenge for customers is developing a strategy and identifying partners,
and then implementing the business side of the federated challenge.”
A question of trust
“Technologists hate me when I say this, but in some ways, technology is the easier part of the problem -- getting two computers
to talk to each other,” Liberty Alliance’s Nicholson says. “The other piece of this is that having two computers talk to each
other doesn’t necessarily guarantee a trusted relationship.”
Dan Blum, senior vice president and research director at Burton Group, defines trust as “the ability for an organization to
take action based on its relationships.” It’s one thing to say that two systems are related -- that an account on one maps
to an account on the other, for instance -- but in order to act on that relationship, organizations must name their terms.
For example, my digital identity gives me certain roles, privileges, and authorizations within my own IT infrastructure. But
how do those attributes apply to the systems of a partner organization with a completely different operating environment?
How much authority do I have over that partner organization’s data? What data am I allowed to see and what can I change? Within
our federated relationship, how can my employer’s partner organizations trust that my identity accurately reflects my current
status within the company? How can I ensure that I respect my partners’ privacy policies and that they respect mine?
According to Blum, a truly effective federated identity system will model the way business relationships are formed in everyday
life. The Holy Grail is dynamic federation -- the ability to engage in activities on the fly, even when no prior trust relationship
exists. Key to enabling dynamic federation will be the concept of an identity network, where if A trusts B and B trusts C,
A knows it can also trust C. To create such a network, however, partner organizations will have to establish both a shared
set of rules and some idea of accountability.
Roles and responsibility
Accountability is especially important when you consider the potential ramifications of federated relationships. Far from
being a mere technological hurdle, in a federated environment, a failed transaction translates into business headaches and
potential liability. Addressing these concerns remains one of the crucial challenges facing companies considering federated
identity.
Consider the example of a financial services company whose application is embedded in an enterprise portal via federated SSO.
Suppose a user begins a transaction using the portal interface, but the session times out before the process can be completed,
causing the user to miss a trading opportunity.
The enterprise portal knows nothing of financial transactions; it was merely observing standard policy by logging out an idle
user. On the other hand, from the financial application’s perspective, it never received a completed transaction request.
In this situation, which company accepts the liability for that failed transaction?