• Sidebar: Proposed Web Services Security Specifications

A software authentication gateway called TrustBridge will allow companies to verify the identities of users coming from other companies' systems, making it easier to open internal resources to trusted partners. Microsoft’s Passport authentication service will also be revamped to exchange authentication information with TrustBridge-based systems. The earliest deliverables won’t arrive until 2003, but Microsoft is moving now to influence standards for Internet-based authentication and to encourage customers to migrate to Active Directory (AD) and Windows .NET Server.

The Problem: Sharing Internal Resources

The TrustBridge software is intended to make it easier for organizations to share internal resources with individuals and applications at partner organizations. For example, a software company might want to allow its public relations firm to read technical specifications and marketing plans for an upcoming product. Ideally, users at the PR firm could access information at the software company with a single sign-on, without having to log on first at the PR firm and then again at the software company.

However, the software company must somehow authenticate (verify the identity of) the PR firm’s users to ensure they can be trusted. One common solution is multiple user accounts: the software company creates a user account for each employee of the PR firm and grants that account access to the appropriate documents. However, maintaining multiple accounts is costly and creates security risks: for example, an employee might be fired by the PR firm but still have access to the software company's files through an account there. A multiple-account solution usually does not provide single sign-on: the user generally must log on to each account. These problems are compounded when a company is dealing with tens or hundreds of partners and wants to grant different levels of access to each one.

Passport—Microsoft’s single sign-on system for Web users—suggests an alternative to multiple accounts. (For background on Passport as it stands today, see "A Closer Look at Passport" on page 12 of the Oct. 2001 Update.) Organizations could simply store all their user accounts at a single trusted organization like Passport and let that organization authenticate all users. Here the problem is that the trusted organization becomes a fat target for attackers and a single point of failure.

TrustBridge will enable an organization to use a third solution: "federated identity." In a federated identity system, each organization authenticates its own users and maintains their user accounts. When a user wants to access resources at a partner organization, the user’s home organization forwards proof of the user’s identity (authentication data) to the partner; the partner grants access based on the degree to which it trusts the user’s home organization. So the PR firm discussed above authenticates each employee and forwards an employee's authentication data to the software company when the employee attempts to access the software company's files. A group of organizations that trust one another in this way is called a "federation." (See "Bob Muglia on the Concept of Federation" on page 22 of the Dec. 2001 Update.)

A federated identity system can be more secure and maintainable than one that duplicates or centralizes accounts, because a single copy of the user’s account information and associated secrets (such as passwords) stay with the user’s employer, Internet service provider (ISP), or some other home organization the user trusts. Federated identity can also provide single sign-on: a user might authenticate once with the home organization, which authenticates the user to partner organizations without further action on the part of the user.

Identity Based on Web Services

Installed at an organization, the TrustBridge software will act as the organization’s gateway for federated identity. It will exchange authentication data with an organization's partners, translating between the organization’s internal authentication systems and those of its partners via a common interchange protocol. The interchange protocol will enable organizations in a federation to use a variety of authentications systems internally, such as Kerberos (widely used in Windows), Remote Authentication Dial-In User Service (RADIUS, used by the Windows Routing and Remote Access service and many ISPs), and systems based on Public Key Infrastructure (PKI).

The interchange protocol used by TrustBridge will exploit Web service technology. It will send and receive authentication data using the Simple Object Access Protocol (SOAP), the de facto standard message format for Web services, and rely on a set of SOAP extensions called WS-Security to encode authentication data and protect them in transit. Developed jointly by Microsoft, IBM, and VeriSign, WS-Security defines a standard way to carry authentication data and to encrypt and digitally "sign" SOAP messages. WS-Security, in turn, enables SOAP messages to carry many other kinds of security information other than authentication data. (For a quick overview of the WS-Security extensions, see the sidebar "Proposed Web Services Security Specifications".)

Basing the interchange protocol on SOAP and WS-Security yields some advantages for federation of organizations that connect to one another over the Internet and use multiple computing platforms. SOAP messages can be sent over standard Internet protocols (e.g., HTTP), enabling organizations to exchange authentication data without reconfiguring their firewalls. SOAP and WS-Security already have the support of many vendors other than Microsoft, making it more likely that they will be available on platforms other than Windows and work cross-platform. Finally, WS-Security has been designed to support authentication data from multiple authentication systems, enabling it to serve as a bridge among systems.

Basing the interchange protocol on SOAP and WS-Security also avoids some problems with the Kerberos v5 authentication system, the most widely used authentication system that supports federated identity (called "cross-realm" or "cross-domain" authentication in Kerberos). Kerberos is less suited for connecting organizations over the Internet than SOAP and WS-Security: the Kerberos network protocol must usually be blocked by firewalls (to prevent remote logon attempts and denial-of-service attacks on internal systems), and even when not blocked, the protocol is hard to operate across firewalls that perform Network Address Translation (NAT). Kerberos is also less extensible than WS-Security and thus less suited as a bridge protocol: vendors can extend the Kerberos protocol, but can't easily extend Kerberos to carry authentication data from other protocols and bridge between those protocols.

Support via TrustBridge, Passport

Microsoft intends to implement TrustBridge in two major steps.

TrustBridge for Windows Kerberos. In 2003, Microsoft plans to release a Windows version of TrustBridge that enables an organization to exchange authentication data over the Internet with partner organizations that use Kerberos v5 on any platform, including non-Windows platforms such as Linux. Microsoft has not decided on packaging for this software, but Web Services Technical Marketing Director Steven VanRoekel suggests it could be delivered in an update for Windows .NET Server, or in the next version of Microsoft's firewall product, Internet Security and Acceleration (ISA) Server.

Passport. Microsoft will revamp Passport so that it uses Kerberos and exchanges authentication data with Web sites and companies using the interchange protocol supported by TrustBridge. Also, Windows .NET Server will be able to send authentication data to Passport and accept authentication data from Passport and map Passport user IDs to AD accounts. With other planned Passport improvements (such as verification of Passport users' identities when they sign up), these advances will enable organizations to federate with Passport, opening up useful scenarios. For example, a business using TrustBridge (or a compatible third-party solution for another authentication system) could grant access to internal resources to any individual with a Passport ID. Or, users at a federated ISP would be able to gain access to Passport-protected Web sites without logging on again—Passport would understand the authentication credentials assigned when they first signed in to their network. (For further information, see "Passport Changing from Closed System to Trust Broker" on page 21 of the Dec. 2001 Update.)

Microsoft hopes that third parties will eventually create gateway products like TrustBridge that connect other authentication systems (e.g., RADIUS, PKI protocols) through the interchange protocol. Because IBM cooperated in developing the Web services specifications used by TrustBridge, it is likely to support them in future products, but has announced no specific plans to do so yet.

Goals: Define Standards, Spur AD Adoption

The fact that TrustBridge won't arrive for at least six months, and perhaps a year or more, and the lack of details about it (such as its packaging) suggests that the announcement was primarily an attempt to define specifications for Web services before competitors—particularly Sun Microsystems.

In Feb. 2002, Microsoft, IBM, and about 50 other corporations formed the Web Services Interoperability Organization (WS-I) to suggest a broad range of standards for Web services (including the specifications that TrustBridge will use). Although many Microsoft competitors, such as Oracle and SAP, have joined WS-I, Sun has not. Among other reasons, Sun is worried that Microsoft will use its industry clout to define specifications that support Windows and the .NET platform instead of Java-based solutions.

By making the announcement now, Microsoft is hoping to convince customers that the proposed specifications will actually find their way into shipping products in 2003. Equally important, the company hopes to convince lagging Windows shops to move their directories to AD and purchase Windows .NET Server. Finally, the announcement puts technical weight behind Microsoft's promise to open Passport to federation, which could convince more Web sites to adopt Passport for authentication.

Resources

Microsoft's Federated Security and Identity Roadmap, including more details about its plans for TrustBridge and Passport, is at msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsfederate.asp.

For background on PKI, see "Windows Public Key Infrastructure Extends Security" on page 3 of the Dec. 2001 Update.

For further information on Passport federation and Kerberos, see "Passport Changing from Closed System to Trust Broker" on page 21 of the Dec. 2001 Update.