Now that more software in the cloud and the enterprise requires interoperability, single sign-on (SSO) is the one way every application can ensure its data is properly authorized. But a proliferation of competing Web services models and security vendors have inadvertently managed to move enterprises away from this goal.
On second thought, perhaps the stateless model for the Web wasn’t such a good idea. Sure, it made serving up hypertext easier. And it enabled the first model for distributed applications on a global scale that actually worked. But it’s left us with a significant problem, one so unique and complex that inevitably, enterprises like yours may need to solve it by making tough choices and rolling their own solutions.
True, the typical technology story is about some vendor’s new, or announced, or projected “solution.” This story is actually about a loophole, for which a Microsoft product manager recently told a conference there are “no absolute answers,” despite all the progress that company and others have made in reaching a common diagnosis.
It has to do with identity: in this case, how software attributes requests for resources to individual users. Without some notion of identity, of ascertaining who is making requests for data, modern applications cannot function securely — which today is the same as saying they can’t function. But the service models on which distributed applications depend do not attribute identity to users. They require added-on technologies to affix real-world identities to service requests. That’s where the problem starts.
Who Gets to Say Who You Are
All distributed, networked applications today are designed around simple Web services. In most respects, this model is efficient, elegant, and cost-effective. If all information processing were conducted not online but rather by mail (not the electronic kind), then the Web services model would look like any company’s basement mail room. Someone would open up envelopes containing forms sent and signed by customers requesting some information. If a sender filled out the form properly, the office worker would send her back another form containing whatever information she requested, or a simple rejection.
The assumption is that the mail handler would trust the identity of the return address on the corner or back of the envelope. After all, who would dare forge a false return address? In the old world of the postmaster, the problem of trust is resolved by certified mail, since naturally, everyone trusts the Post Office. In the modern world of distributed applications (in which the Web now plays a critical role), there is no central Post Office. In its place is a cluster of third parties, independent services that earn their living certifying — or rather, authenticating — the users of services such as Microsoft Exchange and Salesforce.com, and the providers of services such as PayPal and FreeCreditScore.com. In keeping with the trend of borrowing ominous sounding terms from science fiction, these third parties are called identity providers.
Two centuries ago, the evolution of the Post Office was driven by the need for consolidation — for one centralized, trustworthy service to shuttle messages between two points on the map. With the Internet as the backbone of today’s distributed applications, competition works against consolidation. The result is a plethora of competing solutions, with names that call up metaphors ranging from ballistic missile launchers to political action committees: SAML, SWT [pronounced “swat”], WRAP, WS-* [pronounced “W.S. Star”], Shibboleth, Liberty Alliance. Their simultaneous existence has itself given rise to a handful of competing proposals for how those solutions become interoperable.
The Promise(s) of Claims-Based Identity (-ies)
By design, and for simplicity’s sake, Web services are stripped down to simple request/response message pairs. Because nothing about these messages can be implicitly trusted, distributed applications rely upon identity providers (IdP) to examine the signatures attached to them, and authenticate their claims to identity. Without this basic bond of trust between the relying party (RP) and the IdP, all business conducted online today would disintegrate, and the foundation of modern online commerce would collapse. There is no safety net; this has to work.
The closest that Windows has come to a truly viable, efficient identity provision service is a system inspired by Web services. Claims-based identity is a kind of role reversal for the server/client model, wherein the client asserts its identity and the server (the RP), and in an effort to pin down that assertion, asks the client for data that can prove its claim. This challenge and response continues, perhaps indefinitely, until the RP is either satisfied or convinced otherwise. The data the client provides is verified against the database from the third-party IdP, whose identity has already been established, thus forming a bond of trust. Once the RP is satisfied, it grants the client a token — a nugget of XML-encoded data whose basic contents represent the IdP’s certification that the client is privileged to be using the services it’s requesting.
The concept of claims-based identity is at least a decade old, perhaps longer. As such, it’s had plenty of time not only to mature, but to be fruitful and multiply. There are now more than a handful of identity claims formats. The differences between them may actually be trivial, though they’re quantitative enough to render these formats effectively distinct and unique.
“That’s one of the challenges, to get everyone to agree on a protocol for passing these tokens around, and what are the tokens themselves going to look like, and how do I get them from point A to point B,” stated the co-founder of .NET developer training service Pluralsight LLC, Keith Brown, at a recent Microsoft developers’ conference — specifically, to a room full of IT professionals who had been invited to tell Brown, along with other Microsoft representatives, how they’re dealing with the multiple-format problem.
This has been going on for a decade,” Brown said. “This started with SAML way back in 2000. These protocols have been developed, and the problem is that there are a plethora of them. Everybody’s got them,” he continued, before referring to a homebrew solution one of the attendees cooked up to solve the claims translation for his own company. “I’ve never even heard of it before. It’s ‘Protocol X.’ And the SAML guys have the SAML protocol stack; Microsoft has WS-*; there’s a new protocol out called WRAP; and SWT. There’s all these different protocols out there.”
A Token Solution, or Just a Token?
In recognizing that distributed software needs to be interoperable with other distributed software, multiple vendors have prescribed approaches to resolving each other’s problems, ways to trade incompatible tokens for compatible ones, embracing the even bolder ideal of identity federation. Now, major players like Microsoft, Oracle, Novell, CA, VMware, Siemens, SAP, and IBM (via Tivoli), plus new and emerging brands such as Ping Identity, Symplify, Radiant Logic, PortWise, and Entrust are all offering identity federation platforms, resulting in more ways to federate the various claims-based token standards than there are standards.
Everyone wants to be the identity federation, the “United Nations of Me.” Not just a member state in that federation, but its capital.
Microsoft’s play for the identity federation market began last November with its rollout of Windows Identity Foundation, essentially an API that provides a layer of abstraction between .NET-based Web services and the multitude of claims token formats with which they may have to interoperate, if they’re to effectively trade identity data with one another. That was followed up in May with Active Directory Federation Services 2.0, which extends its support of security token formats beyond WS-* to include Security Assertion Markup Language (SAML), believed by many to be the claims market leader, and the basis of Novell’s and CA’s product line.
When WIF and AD FS were first announced, Microsoft marketed them to systems developers as a way to “externalize” the problem of identity management, divorcing that topic from the logic of the applications they’re building. The key takeaway from their message was “Keep using WIF and the problem will migrate elsewhere.” Taken to its extreme, “externalizing” the problem could become another way to pass it down the chain — to make someone else deal with the architectural decisions imposed upon businesses by dueling identity systems.
“Claims-based identity is the identity layer that the Internet has been missing,” program manager Stuart Kwan told me last November. “Windows Identity Foundation is our contribution to making it possible to build applications that will plug into this missing identity layer, and make it really easy for you, so you don’t have to think hard about it anymore. . . Most developers don’t have the time to spend to become an expert in the SAML protocol. They just don’t. And what we’re offering to them is, you don’t have to. You just need to learn the programming model of WIF and claims-based identity, and you’re good to go. You can leave the, ‘What knobs should be turned and what underlying mechanisms are actually going to be used,’ to the IT professionals who are going to deploy and manage your application, who really do become experts in things like SAML protocol, or X.509-based cryptography.”
In retrospect, the notion of “leaving it to the professionals to fix” may not have been the most federation-friendly approach. The very next day, a group of those IT professionals who are going to deploy and manage your application, showed up at Keith Brown’s chat session, along with several security developers. There Brown, Kwan, and their colleagues got an earful. Politely, but firmly, the professionals related their stories of rolling their own solutions, creating their own federations between Exchange and Salesforce.com and SharePoint and Domino using duct tape and baling wire.
These are the people whose job it is to craft some way to literally federate the federations — to interoperate with all types of identity services platforms and parse every permutation of claims token format. They’re proud, but they’re not happy, and they’re demanding action.
There were unresolved questions about the limits of claim tokens’ functionality (could a token be used to claim a specific privilege, for example, and have that privilege be parsed across platforms?); whether claims can be used to authenticate the roles of users, including in Active Directory; and perhaps most importantly, what happens when the Web browser in the enterprise seals off access to identity functionality from within the “sandbox” in which Web apps run? The predicaments these implementers face, and gauging the progress Microsoft and others may have made in resolving them since that time, are topics for another discussion.
Related Information from Dell.com: Intelligent Infrastructure: The IT You Already Own — But Smarter.
