If federated identity protocols can’t agree upon a uniform token format, or even standardized processes to arrive upon such a format, then perhaps they could agree upon a set of fundamental terms and concepts they all share. This may be the only key to resolving a major roadblock for enterprises.
Of all the problems with making the twenty or more user identity federation protocols in active use today work together, the most prominent is this: The standards upon which all those protocols are based are themselves moving targets. Thus a fixed solution one month may fail to work next month.
“In order for us to build interconnected systems, we need to have some agreement between all of the people who are going to be using this software and the vendors, on what the standards are for interconnecting identities,” said Stuart Kwan, Identity and Access Group Program Manager for Microsoft. “I don’t know if I would characterize it as any one vendor who is leading here. We all have to work together to make things happen, and Microsoft has been involved with a lot of the standards bodies in this area, in OASIS, in the IETF, and increasingly, other places where these standards have been advancing. . . We’ve been making a pretty major investment in engaging in these conversations, both in the industry and in standards bodies, to help move the ball forward with everyone else.”
Many will recognize OASIS as the standards group behind OpenDocument, the format used in Sun OpenOffice and other Microsoft Office competitors, and Microsoft’s rival for the desktop as recently as 2007. Now Microsoft finds itself working in cooperation with OASIS in the development of Security Assertion Markup Language (SAML), one of the many challengers in the overflowing field of claims-based identity, and the focus of Active Directory Federation Services 2.0, released in May 2010. SAML is also backed (though not always exclusively) by Novell, CA, Siemens, and IBM. SAML now competes in this space with another standard which had been the earlier focus of Microsoft’s expansion into claims-based territory: WS-Trust, one of the WS-* (pronounced “W. S. Star”) specifications that is managed by the OASIS standards group, with the help of IBM, Siemens, and the rest.
In the emerging world of “openness,” entities now openly compete with themselves. Interoperability, as Microsoft has managed to demonstrate in every possible way through its history, bites.
Can a Solution Just Compose Itself?
A glimmer of hope recently manifested itself to Microsoft and all its security identity competitors, in the form of an almost other-worldly new concept. Called composable Web services, it’s the astonishing notion that two endpoints with disparate protocols can actually negotiate new languages between themselves as warranted.
There’s no counterpart for this in reality, so I’ll supply one from fantasy: Suppose peoples living on two separate continents spoke completely different languages. These peoples evolve normally, the exception being that their capacities for language increase at ten thousand times normal speed. One week, a nationality is just learning the basics of Linear-B; the next, it’s using telepathy. Any translator who facilitates a communication between continents one week, won’t be able to translate a discussion between the same parties the next week.
So the translator tries this solution: He devises a process for quizzing parties on both continents about the subject matter of their typical discussions. With results supplied from both parties, he compiles a common taxonomy of concepts between them. He can refresh this taxonomy as warranted, as the two people’s languages evolve, but the taxonomy stays fresh. And how he reads the taxonomy doesn’t have to be translated to anyone else except himself. He can share his methods with others, and those methods may work elsewhere, but the taxonomies they produce are exclusive to them.
In the real world, that taxonomy would be called metadata — in this instance, the basic elements of exchange between Security Token Services (STS) endpoints.
“As we see applications wanting to connect to applications, we’re definitely going to see a need in the identity space for protocols to allow applications to call other applications,” remarked Kwan, “the same way that SAML addressed Web single sign-on.”
You can’t talk to Stuart Kwan for too long without him drawing a diagram of some sort, even if you’re just on the phone with the guy and his diagram is made entirely of words. “Let’s take a more traditional federation case, where say, I have a user who’s in the supply chain for a manufacturing company, and they’re accessing a particular application,” his verbal picture begins. “It’s a hub and spoke, where the manufacturing company is in the hub, and you’ve got all these other companies in the supply chain in the spokes, and there are users who are accessing that federated application in the hub. When the manufacturing company is creating agreements with its supply chain, how much user information should be disclosed make sure it gets the right information about the users, and what kind of information should that be?”
“Today,” says Kwan, “That’s an exercise that is pretty much done on a one-off basis, as people are creating these relationships. I think as cloud services take off, continue to grow in adoption, then we’re going to see more and more of these templatized agreements, such that you don’t need to have a one-on-one conversation with the other side. There will be ways, through things like metadata, we can determine, ‘Here’s the kind of information that you need to send.’”
The “templatized agreements” that Kwan would like to see between federation protocols are, in one sense, patterns: ideals for not only what federated STS endpoints should trade with one another in particular sets of circumstances, but methodologies for how such patterns can be realized and adjusted where necessary. Kwan went on to suggest that the metadata itself may be capable of triggering the generation of scripts whose sole purpose is resolving exchanges between STSes for just this metadata. Since the scripts are not shared entities in themselves, they wouldn’t have to be made interoperable — so for once, Microsoft could make use of PowerShell rather than XML.
“In the metadata today, we don’t talk about the values that are expected to be sent, but instead just the types. So maybe there’s room for us to put encodings on [situations where an STS declares,] ‘I expect this enumerated set of values with this meaning.’ And that’s something we think will happen in various industry verticals, where the information about a person who’s accessing a system has some specific meaning. It might be something in oil and gas versus something different in aerospace, versus something different in financial services, government, etc. In those verticals, they have particular terms and types that they use to describe people, and lists of things that are important for them to be able to agree on. . . within the realms of their [given] industries.”
Composable protocols using negotiated metadata would not, despite the imagery that appears borrowed from the Terminator series, become “self-aware;” instead, it would require constant monitoring, including someone to manage and run those scripts. Without a precise and well-considered plan for how to manage the products of these operations, the results might actually be more comparable to Jurassic Park.
The Role-Playing Game
One factor that could potentially determine whether evolution gets out of hand in the future is the limitation security engineers place today on how much information the metadata is allowed to contain. Here’s where we discover that some engineers became spoiled by the comparably rich contents of FBA’s old security tickets.
In FBA (which was not designed for portability), Microsoft and others designed security tickets (not tokens) which encoded not only the authenticated user, but data on the access privileges which the identity provider granted. In other words, not just who is this guy, but what? Is he a mail admin? A SharePoint admin? A department head? This is critical information to Active Directory.
Last November, at a Microsoft conference session where the subject of metadata in token negotiation was raised, several developers and admins appeared eager to leverage metadata to resurrect role-based authentication. In response, Keith Brown, co-founder of .NET training provider and Microsoft partner Pluralsight LLC, suggested it might not be such a good idea: “I don’t know that I would try to use claims for role-level access,” Brown told them. “Your biggest value right now in this space, which is evolving, is the federation capabilities that you’re going to get, to be able to. . . have single sign-on. Let’s solve that problem. Trying to get any finer-grained authorization like that, you’re kind of overloading something that people aren’t really trying to solve right now.”
The alternative Brown suggested involved a kind of “trust topology” (my term, not his) where federated RPs are distributed in such a way that they’re only used by clients with the same general requirements. In other words, make the RPs as vertical as the industries they serve, so they don’t have to educate each other too deeply.
“The challenge with authorization is that every app is different, so it might need to have a different, very specific set of permissions,” said Brown. “When you start factoring that up [into a common list], what you’re doing is losing control of that authorization data, you’re centralizing it, so it may be harder to change. And if that thing is not really shared across multiple apps, then I think you’re just making your life harder. So what you really want to think about is, where should a claim be issued from? It should be issued at the location in the trust chain where people can share it, where multiple things are worried about. If only my app cares about this, then really, only my app should be populating those claims.”
Since that time, however, Microsoft’s Kwan told us, security engineers appear to have warmed up more to the idea of encoding roles and privileges along with metadata. Most metadata, he said, may be comprised of numerous, ordinary switches and “knobs,” settings which may be toggled this way or that way — for example, for supporting the stronger SHA-256 encryption algorithm as opposed to deprecated, but still oft-used, SHA-1. Here’s where yet another open identity protocol — this time, the open source project OAuth — enters the picture. Used now mostly for consumer-grade Web apps, OAuth impressed Microsoft with its ability to delegate levels of responsibility for performing deeper functions within an application —responsibilities that applications would otherwise have had to guess for themselves — without disclosing data in such a way that it violates users’ privacy.
“Say I’m on Facebook and I want to find out what my MSN Buddy List is, so I can find out if any of them are also on Facebook. The old way to do this was, you had to provide your Windows Live username and password directly to Facebook in order for it to be able to go read your Buddy List — and that wasn’t desirable, obviously. So OAuth was invented so that you could delegate access to Facebook, not give them your password — instead, go log onto Windows Live ID and give Facebook directly permission to get some specific thing out of your profile at Windows Live, if only for a specific period of time. I think we’re going to see other scenarios like this, but in the more professional cases, [for example], where I have a Zoho application which wants to put a meeting reminder onto my calendar in Hosted Exchange. How is it going to be able to do that, to get the rights to do that, without really complicating the developer experience, [and] complicating the end user experience?
“As those scenarios come up, we’ll definitely see a need to make further technological advances in identity,” remarked Kwan. “I don’t claim that we’ve got all these things figured out yet, but the cloud, I think, [is going to trigger] another surge in this area, and we’ll all be working together to make those things work.”
In another era, it was often said that one company appeared to be calling most or all of the shots for technological standards. Now that Microsoft is resolved to building on top of platforms constructed by others, and in a more transparent way than ever before, it appears the shots are coming from all directions. Even with the online identity problem now ending its first quarter-century, there appears to be no single “leading candidate,” no “favorite,” not even a “default.” Just several dozen entities swimming in the same sea, each of them learning, as if for the first time, how to trust one another.
Related Information From Dell.com: Create a Network Roadmap.