Issue No. 01 - January/February (2005 vol. 9)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MIC.2005.16
IDENTITY MANAGEMENT, ACCESS SPECS ARE ROLLING ALONG
The concept of streamlined single-sign-on network identity and access management moved forward in the last quarter of 2004, with product announcements from prominent vendors, advances in protocol agreements by industry and standards groups, and more visibility among enterprise users.
A certain amount of long-term uncertainty remains about whichidentity-management technology will fit into a given architecture as the applications underlying interorganizational communications depend less on Web browsers and become more capable of standalone interchange. However, the widespread adoption of federated identity — in which users receive trusted access to more than their home network's resources without having to sign on to each new site separately — is reaching critical mass.
Joining the Alliance
Perhaps the best signal was IBM's October 2004 announcement that it was joining the Liberty Alliance Project ( www.projectliberty.org), a multinational alliance of more than 150 members developing an open standard for federated network identity. IBM's joining Liberty might not hold the same significance for identity-management technology that its support of Linux did for the open-source model. However, it is significant enough to compel vendors and users to contemplate how the various identity standards — from Liberty to the WS-Federation standard proposed by the Web Services Interoperability Organization ( www.ws-i.org) to OASIS languages ( www.oasis-open.org/home/index.php) — will roll out in coming months and years, and how vital each will be in network architecture.
Joe Anthony, director of integrated identity management for IBM Tivoli, says the marketplace has evolved in stages as organizations realized how complex internetwork authentication would be. Citing the three central technologies that emerged in the past three years — OASIS's Security Assertion Markup Language (SAML), Liberty, and the Web Services stack — Anthony says IBM developers realized they couldn't ignore any of them.
"We would have customers working with any of those three, and the challenge was, any of their partners could be working with any of those three as well. To [ensure that] we could bring a full-fledged offering to the table, we had to go ahead and support Liberty."
The most prominent example of the market clout attaching itself to Liberty was the deal that pushed IBM to formally join the organization: IBM and Liberty member France Telecom's mobile-service subsidiary, Orange, agreed to a US$50 million project in which IBM would build single-sign-on capabilities for France Telecom and its partners.
The IBM–Liberty relationship might have surprised some people. However, IBM and Microsoft are also the two major powers behind the WS-Federation technology, which could overlap with Liberty, so those involved in the standards effort say they saw it coming; IBM has been developing Liberty-compliant products for some time.
"In a way, this is kind of the last act of the drama, if you will," says Hal Lockhart, a contributor to the OASIS Web Services Security and SAML technical committees and cochair of OASIS's Extensible Access Control Markup Language (XACML) technical committee. "I think we've come full circle."
WILL THE CIRCLE REMAIN UNBROKEN?
The technological circle Lockhart refers to is the tight relationship that's developed between the SAML specifications and Liberty's Identity Federation Framework (ID-FF) specs. Both organizations began working on their specifications about the same time (in 2001), but SAML was originally a vendor-driven answer to the single-sign-on quandary. Liberty was largely driven by end users looking for more rigidly defined user cases to reduce the amount of customizing necessary with early SAML specs.
Many of those early near-misses are fading. In fact, the two technologies are about to reach a major milestone with the imminent finalization of SAML 2.0, in which the SAML specs will basically be a superset of the Liberty specs.
"The dozen or so companies that started SAML did so primarily to address some short-term problems we all felt were retarding our market," Lockhart says. "One of the first major milestones was convincing the people who were involved in Liberty to build on SAML, which was definitely not a foregone conclusion by any means. Secondly, where Liberty had done a bunch of good work that had extended SAML, there were some people in the organization who thought, 'Well, we're kind of a standards body, let's keep going,' but other people said, 'No, lets submit it back to OASIS so we'll have one standard and everybody can rally around it.' So they did that, and now we've reached the point where we're all but finished ratifying SAML 2.0, which incorporates and in some cases generalizes the good work done over at Liberty, and Liberty is basically fully embracing SAML 2.0, saying it's Liberty ID-FF. This process could have gone off the rails in many places, but now we're in a very good place."
Essentially, the SAML–Liberty specs rely on properties known as assertions. There are three major types:
• authentication assertions declare a user's identity;
• attribute assertions state particular details about a user; and
• authorization-decision assertions state what a given user can do at a particular site.
When a user successfully requests access to a protected resource, an application known as a SAML authority issues a digitally signed token that's good for further requests within that issuing application's "circle of trust" without requiring reauthentication.
Liberty is also finalizing the next stage of its architecture, the ID-WebServices Framework (ID-WSF), which enhances basic single-sign-on capabilities in a circle of trust to include features such as anonymity, permissions-based attribute sharing, and security profiles. Twelve vendors earned ID-WSF conformance certification in the organization's first demonstration of the technology in October 2004.
A Tortoise in the Race
If the SAML–Liberty technology seems to be the hare leading the race to become the lingua franca of identity management, a tortoise might also be loping along behind: the WS-I's WS-Federation concept. At this point, however, it remains just a concept. Developers from IBM and Microsoft have written several white papers detailing the basic ideas behind it ( www-106.ibm.com/developerworks/webservices/library/ws-fedworld/), but the work hasn't advanced into the formal WS-I process.
WS-I representative Christian Danella says that WS-I can provide information about what they're doing to address Web Services security, but that they haven't started a profile to address federated identity management.
But IBM's Anthony and several OASIS members say that writing WS-Federation off as a nonstarter could be premature.
"SAML is a good assertion technology," Anthony says. "It's better for a point-to-point relationship — better than jumping into a full-blown federation where you may have one-to-many — because you have to customize the content of the assertions quite a bit, depending on the partner you were working with. But to get started two years ago, that was fine for a certain number of relationships, and our products supported that for the last two releases of our access manager.
"Then, as you got into Liberty and realized you were working preferably with a larger circle of trust, it was important not to do so much customizing from partner to partner, so you standardized more of it, and you started working toward an ability to do a single-sign-on within that circle of trust. It worked for browser-style artifacts and was suited for that environment pretty well." Looking at it from a WS-Security perspective, however, with a more active client profile in which browsers move in and out of environments and applications start working together with program-to-program communication linking supply chains, Anthony says that having a broader base of functionality such as the WS-Federation, WS-Trust, and other WS-framework components is important.
Prateek Mishra, cochair of the OASIS Security Services technical committee, which oversees SAML development, says it's impossible to chart a likely course from SAML–Liberty to WS-Federation right now.
"Most of what we're doing today, and will do for some time, is Web applications," Mishra says. "People are actually getting a lot of value out of Web applications. Now, when you tell them about the Web services model, which has many more powerful properties than Web applications, they're certainly interested, and it feels like the next step, but where are the pinpoints to make them go there? I think all of that is still in progress. Sure, in theory I think Web services, broadly speaking, are the future. But is that future two years away, or 10?"
Lockhart says it might take a while for the Web Services stack to sort itself out, but it could have profound effects on identity-management architectures.
"There's a whole body of thought that Web Services are machine-to-machine, application-to-application communications, contrasted to the Web where there's a human being in the loop," he says. "That changes identity management. In many situations, it reduces the number of identities you need to manage by two or even three orders of magnitude. You may not reflect all individuals' identities when you have an environment of application-to-application communication, and some of the issues around identity management are affected by that.
"They're also affected by the fact that in a machine-to-machine environment, applications will be built to have new capabilities, whereas a lot of the work we've done in the Web world is to say, 'Browsers are browsers; they can do just this and not anything else.' So we need a solution that lives with that restriction. In the Web services world, we don't necessarily see the same restrictions, so it's really not clear whether identity management is going to be primarily focused around Web technology or ... Web services."
Although some analysts predict a gradual convergence of the WS-Federation specs and the Liberty specs, Liberty officials say that isn't gospel.
"A lot of this is driven by people's adoption of any technology," says Simon Nicholson, chair of Liberty's business and marketing group. "You learn to never say 'never' in this space, but unless convergence is being driven by underlying deployments and adoption, it becomes an academic exercise."
Almost across the board, though, from the Liberty–SAML success to the recent announcement that Cisco and Microsoft would work to make their hitherto incompatible network access protocols (Cisco's Network Admission Control and Microsoft's Network Access Protection) interoperable, vendors are learning quickly that making products that cut across boundary lines is the only way to stay viable in a marketplace increasingly demanding federated identity capabilities. Microsoft's once highly publicized (and in some quarters, feared) proprietary Passport technology, for example, is no longer even considered competition by standards groups.
"The whole identity space is all about interoperability in the first place, as opposed to 'My protocol is better than yours,'" says Lark Allen, a member of the Trusted Computing Group, which focuses on providing a standard for hardware such as encrypted security chips and their software interfaces within the network. "The whole value proposition is interoperability. It's only natural that the products you've seen on the market reflect that."