Federated identity management and Web services
The traditional approach to solving this problem has been Single Sign On (SSO), the centralization of access control information into one server that requires special plugins (e.g., "Web agents" for Web servers) to retrieve the information. Every application needs to be "SSO enabled" by programming to the proprietary API, different for each competing vendor. The coding task usually falls to the IT organization. Overall, this technology has not been as successful as originally hoped, with many SSO implementations either behind or experiencing scalability challenges.
Traditional SSO is impractical for extranets or Web services because partners may not agree on a single SSO vendor, and it is not possible to have a unified database. Such a database might have to include up-to-date information on both companies' employees, for example, a task hampered not just by practical but also privacy and business considerations.
Indeed, identity information and access control policies are some of the most valuable and frequently used data in any IT organization--chances are, every application and every system needs to be able to access it. Just as other large scale integration challenges are increasingly addressed by employing Web services protocols, it makes a lot of sense to do the same for access control. Instead of coding to a proprietary agent (which in turn uses a proprietary protocol to communicate with a particular brand of identity management server), applications can make Web services (SOAP) requests to authenticate users or authorize transactions.
Where Single Sign On (SSO) relied on establishing a central server accessed using special agent libraries that had to be integrated into applications, Federated Identity Management leverages lessons from the U.S. federal system and application integration. Local applications or organizations maintain their own repositories which respond to queries from both local and remote applications with security assertions containing user attributes and roles. When encountering external users, the local applications query other federated repositories to authenticate and authorize these non-local users.
SAML (Security Assertion Markup Language) is the dominant Web services standard for federated identity management. It defines a set of XML formats for representing identity and attribute information, as well as protocols for requests and responses for access control information. The key principle behind SAML is an assertion, a statement made by a trusted party about another. For example, a federated identity management server would produce assertions about the identity and rights of users. An individual application does not need to have direct access to the user repository or trust a user, it only needs to know and trust the assertions source. Assertions can be encoded in browser requests or included in Web services transactions, enabling logins for both person-to-machine and machine-to-machine communications. This is another first, the ability to use the same standards protocol for both back-end transactions and Web portal access control. For more on SAML, see http://www.securewebservices.org/archives/16-The-S-in-SAML-isnt-for-Simple.html.
Increasingly, regulatory and security requirements demand not just authentication, but also the other A's of AAA – fine-grained authorization and accounting. In addition to providing a means of enabling access for partners and customers, federated identity management technologies improve security by controlling access on an operation-by-operation basis and providing a detailed audit trail. SAML assertions, for example, can include the entire evidence chain used to make the access control decision. The evidence serves as a legal record of who accessed what data at what time, why and on whose authority.
This added security and accountability is especially important for unattended machine-to-machine transactions, which increasingly means Web services. With no humans to oversee transactions or assume liability, Web services rely on federated identity management instead.
Just like Web services, SAML (and other FIM technology) is not just for securing connections to external parties. It is also useful internally, since many large companies today have many internal business units with separate access control systems. Instead of attempting to replace these systems with a central server, it is now possible to leave them in place and wrap them with SAML interfaces. While the broader task of corporate identity management still remains, a federated approach based on open Web services standards makes it cheaper and more scalable.
In conclusion, federated identity management makes possible the vision of "identity as a service," where authentication and authorization functions are Web services available to any application in the enterprise SOA. It breaks the traditional lock between WebSSO shim & server, disintermediating many access control vendors in the process. Instead of installing agents and writing custom code, single sign-on enablement is now a matter of standards support. Federated identity management applies the concept of a federal system to the ever-present problem of access control, and by using Web services standards makes secure connectivity universal. In turn, Web services use federated identity management technology to secure business transactions. And that's how these two seemingly unrelated topics are deeply intertwined.
biography
Eugene Kuznetsov is chairman & chief technology officer at DataPower, the leading provider of XML-aware networking devices in Cambridge, Mass.