At its TechEd conference this week, Microsoft is pushing its newly upgraded Active Directory Federation Services (ADFS) technology as the foundation for identity in cloud computing environments, but some analysts point out there are still more pieces to come in the complex federated identity puzzle.
Enterprises often use Microsoft’s Active Directory as the foundation for enterprise-wide identity and authentication management, and many are wondering how they might extend or add to these controls to prepare for cloud-based computing.
“When you talk about migrating infrastructure, ADFS 2.0 gets you that interoperability between private, public and hybrid clouds,” says JG Chirapurath, Microsoft’s director in the identity and security business group. “Identity is the glue that will make it all work. We firmly believe that it’s all about identity.”
But what is Microsoft’s identity glue, ADFS 2.0, really all about?
ADFS 2.0, which was released in early May, “doesn’t require changes to Active Directory server — it’s a separate server that knows how to talk to Active Directory,” says Burton Group analyst Bob Blakley.
ADFS 2.0 can be expected to be used in different scenarios — Microsoft likes to point to some early deployments by Thomson Reuters and the government in British Columbia for use in single-sign on in their organizations.
Blakley says there’s no doubt ADFS 2.0 is a central piece of Microsoft’s identity management strategy, providing a two-way gateway for sending and receiving claims-based requests, as Microsoft calls them, using SAML-based tokens containing information about users and what they want in terms of information and access.
ADFS 2.0 supports the open standard protocol Security Assertion Markup Language (SAML) 2.0, and Microsoft late last year showed it could operate with other vendor products based on SAML for identity management.
“SAML interoperability is built into ADFS 2.0,” says Joel Sider, a Microsoft senior product manager. “Microsoft has a responsibility to step up and say there should be protocol neutrality. The most important thing is that people who are invested in identity can take it to the cloud,” he adds.
“Federation is now important because of the cloud. It’s not domain-centric — it’s looser partnerships, more loosely aligned. We need a way for people to collaborate on a project basis,” Blakley says.
Blakley points out that while ADFS 2.0 is an implementation of SAML 2.0 integrated into the Microsoft infrastructure, it supports the most important aspects of SAML, though strictly speaking, not the entire SAML profile. “With the SAML security token service in ADFS 2.0, if you have a Windows Server 2007 with Active Directory domain services, and users are just logging on, they can now go to applications outside the domain and get access.”
Moreover, ADFS 2.0 is expected to be baked into many future Microsoft application products, such as SharePoint 2010. But the reality is today legacy applications don’t have the ability to easily work under a SAML-based framework, though they can be made to work that way.
IBM, for instance, just announced an updated version of its SAML-based Tivoli Federated Identity Manager, Tivoli Access Manager and Tivoli Security Policy Manager, saying it can now supply SAML-based software plug-ins for several applications, including SharePoint.
“You can take an in-house application and use SAML to connect to this,” says Ravi Srinivasan, senior product manager, IBM Tivoli Software. Given the complexity of identity-management terminology, he notes that IBM uses the term “attributes” where Microsoft uses the term “claims” to describe what’s requested, given or denied in SAML 2.0-based tokens. “You query us and say, you’re asking me for this information. So tell me who you are,” says Srinivasan, describing how the back-and-forth of federated identity management works.
But what’s missing in the Microsoft identity lineup is a way to establish policy rules and execute them for authorization, Blakley says. “Policy framework is not part of ADFS 2.0,” he points out. There’s detail on the topic in the just-released Burton Group report “Microsoft’s Future Identity Fabric,” authored by Blakley.
To get that needed “access-controller class” capability today using ADFS 2.0, he says enterprises would probably want to look for third-party vendor products from companies such as Omada, Volcker Informatik and BHOLD.
The authorization protocol Extensible Access Control Markup Language (XACML) from the Organization for the Advancement of Structured Information Standards (OASIS) has emerged as the preferred standard for fine-grained authorization.
IBM says it supports XACML in its Tivoli Federated Identity manager product. But it’s unclear if Microsoft is going to go the XACML route, Blakley says. “Microsoft has not announced support for it yet,” he notes. “They’re working on a policy language that’s similar but not exactly the same.”
Federated identity management relies on a claims-based model, so any enterprise looking to use it must start the journey by converting to a claims-based model as quickly as possible, Burton Group advises. “Legacy applications can still be supported in a system whose primary authentication token is claims-based; federation cannot be supported in a system whose primary authentication token is not claims based,” the Burton report concludes.
While a lot of the discussion this week is about federated identity in the cloud, Burton Group says enterprises can start by establishing pilot projects that would give the enterprise intranet users a way to do single sign-on to Active Directory domain resources and cloud-based applications, for instance.
“If Microsoft’s identity management offerings are missing features you find important, consider another vendor,” Burton Group’s report states. “Microsoft has in the past delivered identity management slowly and sometimes late.”