Microsoft Passport, the company's single sign-on (SSO) solution for the Web, has been a controversial technology since its release in 1999. Most Passport-related discussions tend to focus on the product's security and privacy features—or lack thereof. As if in response, Microsoft has integrated a new, more secure version of Passport called .NET Passport in Windows .NET Server (Win.NET Server) 2003 and Windows XP, its latest OS platforms. To grasp the importance of this new Passport, you need to understand the Passport infrastructure, the process of a basic authentication exchange, and the way the product integrates with the new OSs.
Passport-Enabling Web Technologies
Passport uses common Web technologies that all browsers support. These technologies are HTTP, dynamic Web pages with embedded JavaScript code, cookies, and the Secure Sockets Layer (SSL) protocol.
Passport uses HTTP to retrieve Passport Web pages from Passport-enabled Web servers. HTTP lets the software transport Passport-related user information, create and retrieve information from client-side cookies, and redirect browsers from one Web site to another. The software makes extensive use of HTTP redirect messages. HTTP redirect messages let Web sites communicate with one another without requiring configuration of direct communication between Web servers. All communication occurs through the user's browser.
JavaScript code embedded in Web server pages lets Passport deliver dynamic Web content (e.g., personalized Web pages) to the user's browser. Microsoft selected JavaScript over typical Microsoft scripting technologies such as VBScript because all browsers support JavaScript.
Cookies permit temporary and persistent storage of Passport-related information on the user's desktop. Code on Microsoft's Passport infrastructure servers creates the cookies. To store confidential user information, Passport uses encrypted cookies.
Passport uses SSL to create secure tunnels for the transport of confidential user data between browsers and Web servers. These SSL tunnels provide data authentication, confidentiality and integrity protection, and server-side authentication.
Passport Infrastructure
Before I dive into the nuts and bolts of how Passport works, you need a clear view of the Passport infrastructure. You can classify the Passport infrastructure components into three categories, as Figure 1, page 2, shows: the Microsoft Passport Nexus servers, the participating Web sites' Web servers, and the Passport domain authorities' servers. The infrastructure servers that a Passport user deals with are those of the domain authorities and participating Web sites.
The Passport Nexus servers, which constitute the core of the Passport system, provide configuration information to all other servers in the Passport infrastructure. This configuration information includes such items as the Passport user profile schema and the cryptographic keys that secure certain Passport cookies.
A participating Web site is a site that lets its users use Passport SSO to log on. The site's owners have installed Passport-specific code (including the Passport Manager COM object and Internet Server API—ISAPI—filter) on the Web server and have signed an agreement with Microsoft or one of the Passport domain authorities to join the Passport SSO network. Starbucks, eBay, ActiveState, and MSN MoneyCentral are examples of participating Passport sites. You can find an up-to-date list of all participating Passport Web sites at http://www.passport.com/directory.
A domain authority server is a server of a trusted third party that owns a Passport domain and acts as a Passport authentication authority for that domain and the participating Web sites. The domain authority servers for the passport.com, msn.com, and hotmail.com domains are good examples. Microsoft or business entities closely related to Microsoft run all domain authorities. Every domain authority manages a database that contains a secured copy of users' Passport credentials and profile information.
The Basic Passport Authentication Exchange
How does a basic Passport authentication exchange work in a nonWin.NET Server or non-XP environment? Consider a scenario in which a user is working from a Windows 2000 machine. The user already has a set of Passport credentials and isn't logged on to Passport. The user enters the http://moneycentral.msn.com URL in the browser. Here's what happens next:
- To authenticate to Passport and the MSN Money Web site, the user clicks the Sign In icon in the upper right corner of the MSN Money home page.
- An HTTP redirect to the Passport domain authority server's logon page occurs.
- The Passport domain authority server presents the user with a Passport logon screen.
- The user enters the appropriate Passport credentials. The credentials go to the Passport domain authority server over an SSL connection. The domain authority server then validates the credentials.
- The Passport domain authority server writes a set of domain- and user-specific Passport data to the user's machine (in the Temporary Internet Files user profile folder).
- If the user's Passport authentication is OK, the Passport domain authority server generates an HTTP redirect back to the MSN MoneyCentral Web server.
- The MSN MoneyCentral Web server sends a new copy of the MSN Money home page to the user's browser. On this new copy, Passport's Sign In icon has changed to a Sign Out icon. The MSN MoneyCentral Web server also writes a set of site- and user-specific Passport data to the user's machine.
If the user is a first-time Passport user and doesn't have a set of Passport credentials before clicking Sign In in Step 1 of the exchange, the scenario would look slightly different. In this case, Passport first transfers the user to a registration Web page to create the necessary credentials.
An important feature of the basic Passport authentication sequence is that the user's Passport credentials are never sent to the participating Web site. The participating Web sites rely on the Passport-specific mechanisms to authenticate the user.
The credentials the user employs to authenticate to Passport in Step 4 are the user's email address and a password or PIN that contains at least six characters. Passport 2.0 and later support a feature called secure sign-in (aka strong-credential sign-in). This feature requires the user to enter, in addition to an email address and password, a four-digit security key to authenticate to Passport. Passport automatically blocks the user's Passport account key after three attempts to log on with the wrong security key. Strong-credential sign-in combined with Passport's use of the SSL protocol for the exchange of authentication-related data greatly enhances the security of the Passport authentication protocol.
Another way to enhance Passport security is to make Passport users aware of a Passport spoofing problem and its associated risks. A simple precaution you can teach your users is how to check the authenticity of the name attributes of an SSL Passport server certificate (e.g., making sure that the certificate was issued to the passport.com Web site and not to pasport.com) or a Passport Web site's URL (e.g., making sure the URL shows http://login.passport.com and not http://login.pasport.com). These spoofing attacks on earlier Passport versions were also known as bogus merchant attacks. For an overview of these attacks, see David P. Kormann and Aviel D. Rubin's paper "Risks of the Passport Single Signon Protocol" (http://avirubin.com/passport.html).
Revisiting the Basic Exchange
If the user is on the Win.NET Server or XP platform, the OS (rather than the browser) manages part of the Passport authentication. This change clearly illustrates the tight integration of Passport with the new generation of Microsoft OS platforms. The Passport logon screen, which Figure 2 shows, is hard-coded into Win.NET Server and XP. Consequently, with Win.NET Server and XP, the Passport domain authority server doesn't present the Passport logon screen. Rather, the OS displays a Passport logon dialog box whose layout varies depending on the participating Web site from which the Passport authentication process was started. This site-specific dialog box design is called cobranding. As a result, in a Win.NET Server or XP Passport authentication exchange, Steps 3 and 4 are different:
- Step 3—The Passport domain authority server requests the user's OS platform (Win.NET Server or XP) to display the Passport logon dialog box, rather than presents the user with a Passport logon screen.
- Step 4—The user enters the appropriate Passport credentials in the Passport logon dialog box. The credentials go to the Passport domain authority server over an SSL connection. The domain authority server validates the credentials. With the exception of the use of the Passport logon dialog box, this step is identical to that of the previous sequence.
You'll notice two other important differences between the way Passport works on Win.NET Server and XP and the way it works on earlier OS platforms. First, in Win.NET Server and XP, the Passport registration process is different. Instead of redirecting you to a Passport registration page, Win.NET Server and XP start the .NET Passport Wizard, which Figure 3 shows, to guide you through the registration process. You can also manually start the wizard at any time from the Control Panel User Accounts applet. To do so, click Set up my account to use a .NET Passport on the account's Properties page.
Second, in Win.NET Server and XP, you can save Passport credentials in the Credential Manager. This security feature enables SSO functionality based on a secure credential-caching mechanism. Because Credential Manager's data resides in the user profile, the credentials can be cached locally on the user's machine or remotely on a server (in the case of a roaming profile). To store your Passport credentials in the Credential Manager cache, select the Sign me in automatically check box in the Passport logon screen (you can see this check box in Figure 2). To view the Credential Manager's content, open your account's properties from the User Accounts applet and select Manage my network passwords.
Passport and the Privacy of User Information
The problem of universal distribution of personal information is tightly entwined with the ubiquity of the Web. Microsoft understands the importance of effectively addressing privacy problems to winning universal acceptance of Passport's SSO technology. Among the Microsoft privacy-related initiatives is the company's support for the TRUSTe initiative, the World Wide Web Consortium's (W3C's) Platform for Privacy Preferences (P3P) initiative, and the inclusion of privacy-related features in its latest software products (including the latest Passport versions). You can read Microsoft's general privacy statement at http://www.microsoft.com/info/privacy.htm and the company's Passport-specific privacy statement at http://www.passport.com/consumer/privacypolicy.asp.
In Passport 2.0 and later, you can easily modify the content of your Passport user profile and decide on the data you want to share with participating Web sites during a Passport logon session. To do so in XP, open the User Accounts applet, open the account's properties, then select Change My .NET Passport. You've now set up a connection with the Passport domain authority server, and the Edit Your .NET Passport Profile dialog box appears.
Another important privacy-related technology you can use when you're worried about how a Passport-enabled Web site deals with your personal information is Microsoft Internet Explorer (IE) 6.0's built-in P3P support. The W3C drives the P3P project, which is a combined protocol and architecture designed to inform Web users about Web sites' data-collection practices. For more information about P3P, go to http://www.w3.org/p3p.
To check a Web site's P3P privacy report in IE 6.0, select Privacy Report from the View menu, then select a Web site's URL and click Summary. Figure 4 shows the privacy report for the MSN Money home page.
Passport Integration in Win.NET Server
Microsoft has included several Passport-integration features in the forthcoming Win.NET Server, which will let you use a set of Passport credentials to authenticate to a Win.NET Server Microsoft IIS Web server. Passport Authentication now appears as one of the authentication-method options in an IIS Web site's properties. To use this feature, your IIS Web site must be joined to the Passport infrastructure as a participating Web site. (For information about how to join the Passport SSO infrastructure as a participating Web site, go to http://www.microsoft.com/netservices/passport/default.asp.) Win.NET Server doesn't support the creation of enterprise Passport infrastructures, in which an organization is its own domain authority and isn't linked to the Microsoft "Internet" .NET infrastructure. If you want to use Passport to authenticate users of your Web site, you must join the Microsoft Internet Passport infrastructure. To facilitate Passport management, IIS also includes the Passport Manager Administration interface, which lets you use a GUI to set Passport participant Web site configuration parameters.
Win.NET Server Active Directory (AD) lets you define a mapping between a Passport User Identifier (or PUID) and a Windows SID. You can therefore apply Windows SID-based access-control settings to users who have used Passport credentials to authenticate to your .NET infrastructure. An AD account object's altSecurityIdentities property defines the PUID-SID mapping. Although you can use the Name Mappings option in the Advanced view of the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to add alternate Kerberos identities and certificate mappings, you can't do so with PUID-SID mappings. To set up PUID-SID mappings, you must use a Lightweight Directory Access Protocol (LDAP)based editing tool (e.g., Ldifde, ADSI Edit) or Active Directory Service Interfaces (ADSI) to script the creation of the mappings.
Finally, Win.NET Server's IIS server can construct a SID for a PUID on the fly. This feature permits Windows SID-based access-control enforcement for users who have used Passport credentials to authenticate to IIS but who don't have a predefined AD PUID-SID mapping. In this case, the Passport Manager object derives the newly generated SID from the PUID. The problem with this feature is that the newly generated SID won't pop up in resources' access-control editors. In other words, using this SID to perform access-control enforcement requires custom access-control logic coding.
Although Win.NET Server includes advanced Passport support, it doesn't include a Passport-specific Security Support Provider (SSP). You use an ISAPI DLL called passport.dll to enable IIS's Passport support. As a consequence, a Passport user and a Passport-enabled Win.NET Server server can't negotiate Passport authentication—you must explicitly set Passport authentication in a Web site's Authentication Methods property.
Important to Microsoft
The continuing stream of Passport enhancements and developments—and the many resulting Passport versions released over the past 3 years—illustrate the product's importance to Microsoft. In 2001, Microsoft positioned Passport as the basic building block for its consumer-oriented Web services initiative (aka HailStorm). Later that year, Microsoft commissioned Ready-to-Run Software to port the Passport SSO solution to Sun Microsystems' Sun Solaris and Red Hat Linux. (For more information about these developments, go to http://www.rtr.com/Ready-to-Run_
Software/passport_press_release.htm.) In 2002, Microsoft revealed its plans to release a Kerberos-enhanced Passport version in 2003 as the company's solution for federated identification and authentication services on the Web. This effort is code-named TrustBridge. For more information about TrustBridge and federation, see the June 6 Microsoft TrustBridge press release at http://www.microsoft.com/presspass/press/2002/jun02/06-06trustbridgepr.asp.
We'll have to wait and see whether Microsoft's Passport ambitions are realized. Meanwhile, important competitors such as OneName and Catavault have popped up in the Web SSO space, offering valid Passport alternatives.
Also, other major players (e.g., Sun, Novell, Hewlett-Packard—HP) in the software industry are sticking with the Liberty Alliance Project and the Security Assertion Markup Language (SAML) as the building blocks for a Web-based SSO infrastructure and federated Web services. But this article has provided plenty of reasons for gaining a good understanding of .NET Passport and its security features.
