Walk up to an ATM anywhere in the world, insert your bank card, punch in your PIN, and within minutes you can withdraw local currency from your own account, no matter where you normally bank. Aside from a possible service charge, the transaction is seamless. It’s the same as if you were at a branch in your hometown.
That’s a federated system in action. Out of mutual self-interest, using simple authentication at the point of transaction, participating banks have agreed to trust one another to supply funds from their respective vaults. The banks remain separate entities, but the flow of transactions is shared, creating a federated network.
Today, major IT vendors and their customers are looking to this same model as a way to enable the next generation of integrated network services for enterprise employees, business partners, and consumers. As open federated identity standards mature, IT will be able to deploy sophisticated access controls and to secure multiparty transactions across all types of organizations. And there is growing agreement that this vision of the future hinges on the fundamental nature of digital identity.
“When we started this three years ago, identity was seen as just another attribute, just another enabler, for an otherwise bigger problem” of sharing data across companies, says Simon Nicholson, chair of the business and marketing expert group of the Liberty Alliance, an organization that promotes federated identity standards and technologies. “I think that what happened is that, the more people dug into what identity does for them, the more they realized that nothing is going to happen until they resolve the identity issue.”
For Nicholson and others, that issue involves questions as to where user identity should actually reside, the role of technology versus the role of trust, and how open standards can ever hope to rationalize the matrix of permissions required to share user information across an endless diversity of systems and organizations. The long-range payoff of federating identity is radical simplicity, so that both business users and consumers can engage in multi-party activities as easily as they use a single application.
Standards set the stage
According to Burton Group, identity federation combines SSO (single sign-on), identity mapping and account linking, directory services, authorization, and management. Getting all these components to work across distributed, heterogeneous environments is a tall order. The idea won’t become mainstream without broadly supported standards -- building blocks for federated identity that the industry has been working furiously to establish.
The most successful building block to date is SAML, an XML framework for exchanging security information between servers. Developed within the OASIS organization, SAML 1.1 defines protocols for SSO, delegated administration, and policy management. The Liberty Alliance has built on SAML to produce the ID-FF (Identity Federation Framework), which adds account linking, single sign-out, and improved facilities for establishing trust between organizations. In turn, the forthcoming SAML 2.0 specification will incorporate much of the Liberty Alliance’s work in an effort to become a unified standard for identity federation.
To encourage industry adoption, the Liberty Alliance has been proactive in certifying products both for technical compliance with its standards and for real-world interoperability.
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?
Federating between companies in different industries can also raise other, unforeseen issues, particularly in today’s regulatory environment.
“You may be great at manufacturing, but you’re not that aware of the SEC regulations for accessing financial data -- or privacy information … in a hospital,” says Roger Sullivan, vice president of business development for the application server division at Oracle. These issues become even more complex when you consider the multinational nature of most large enterprises (see The Global Challenge).
“One source that we point our customers to is the business guidelines documents being produced by the Liberty Alliance,” Sun’s Shikiar says. “Those raise key issues around federated identity at a generic level -- things around risk, compliance, indemnification, nonrepudiation, issues like that.” Resolving specific issues, of course, is up to you.
Driven by demand
Despite the various business, operational, and regulatory hurdles that must be overcome, federated identity is building real momentum. The standards and technologies developed during the past several years have moved beyond the hypothetical into real-world deployments.
“In the last six months, we’ve seen a lot of the plans that were put into place in 2002 and 2003 now come to maturity with live implementations,” Liberty Alliance’s Nicholson says, citing significant deployments by AOL, Fidelity, and European mobile carrier Orange, among others.
Indeed, businesses that have not yet considered federated identity may soon find themselves under pressure from vendors and partners to get on the bandwagon. Steve Kessler, director of information security at Reynolds and Reynolds, a provider of IT services, solutions, and software to the automotive industry and a Netegrity customer, says his company’s identity efforts are definitely customer driven.
“[Federated identity] is definitely on the road map,” Kessler says. “Four different car companies or retailers have requested cross-portal authentication, which leads into federation. So it’s absolutely something we’re looking at.”
In much the same way that Wal-Mart standardized its warehouse operations around RFID, larger companies may soon begin requiring their customers to enter into federated identity relationships or else pay a premium to access services using traditional means. Given this eventuality, it makes sense to begin planning for federation today.
Implementing federation certainly won’t be as easy as flipping a switch, but it doesn’t have to be a monumental hurdle, either. This is one race in which slow and steady definitely wins.
“You need to take a stepwise approach,” Sun’s Shikiar says. “You need to start with an assessment. Where is your architecture today? Where does it need to be? What standards do I need to embrace and how do they match up with my current architecture?”
As with most promising new ideas, the best policy is to focus on the areas of greatest need first.
“If I’m looking at federation, I would probably want to identify a few areas where it can help me the most, where I can implement it initially,” Shikiar says. “Where do I have existing technologies or partnerships that could be facilitated by this? And within those, which of those partners would be most likely to work with me on this project?”
Before jumping on the federation bandwagon, however, interested organizations must first establish a solid internal identity infrastructure.
“You should be getting your identity infrastructure in order because you can’t share identities unless you’ve got your own under control,” Oracle’s Sullivan says. That means making sound technology decisions that emphasize flexibility and building in federation as a requirement from the beginning, even if you don’t have an immediate need for it.
After all, as Liberty Alliance’s Nicholson says, a federated approach is only natural. “Identity is inherently federated anyway. It’s a distributed thing,” he says. “Is federated identity going to become a core part of how we do stuff on the Web without realizing it? Yes, I believe it will. It solves real issues; it solves real requirements. The protocols may change over time, the underlying technology may adapt and shift and change, but the concepts? Definitely.”