Many e-commerce Web sites maintain their own databases of customer account information, such as user logon names, passwords, and credit card numbers. As a result, users must keep track of numerous sets of account information—often a separate set for each Web site they visit. Users who forget or lose track of the username or password they selected for a particular site account often choose not to return to the site rather than go through the hassle of setting up a new account. Additionally, customers who are concerned about privacy and security, if asked to submit personal information such as their birth date or gender, frequently choose not to establish an account rather than to divulge more information than they'd like.
Smart e-commerce site managers can attract customers—and reduce administration headaches—through user-identity management. Microsoft .NET Passport is an Internet user-identity—management system that lets Internet users use just one login name and password to sign in, access Web services, and shop online at all participating Web sites. Users can control what personal information they want to register in their accounts and what personal information they want to release to the Web sites that they visit. (The Liberty Alliance Project, a Sun Microsystems—initiated group of vendors, is developing a similar system and encouraging Microsoft to join with it.) If you're a Web site developer or administrator, .NET Passport helps you provide a better user experience and saves you time by supporting Internet user-identity management. When you understand what .NET Passport is and how it works, you can build a .NET Passport—enabled e-commerce Web site to better serve your customers and ease your user-management burden.
Services and System Configuration
.NET Passport provides three services: single sign-in (SSI), express purchase (EP), and Kids Passport. The SSI service lets users maintain one .NET Passport user account with which they can access .NET Passport—enabled services, such as personalized MSN pages and .NET My Services (previously code-named HailStorm—for more information about .NET My Services, see Darren Mar-Elia, ".NET Demystified," November 15, 2001, InstantDoc ID 22760). The EP service lets users store credit card information and billing and shipping addresses in an electronic .NET Passport wallet, then purchase goods on the Internet without needing to reenter information for each order. The Kids Passport service supports the Children's Online Privacy Protection Act (COPPA), which requires Web sites to obtain parental consent before collecting, using, disclosing, or displaying children's personal information. (For information about Kids Passport, see the Web-exclusive sidebar "Passport for Kids," http://www.winnetmag.com, InstantDoc ID 24125.)
The .NET Passport system provides a central Internet user-account database and performs user authentication on behalf of participating Web sites, so those Web sites don't need to maintain user-account databases. The system consists of a .NET Passport account database, which stores .NET Passport user accounts, and several network servers, which Microsoft dubs the Registration server, Member Service server, Update server, Login server, Wallet server, and Kids server. The Registration, Member Service, and Update servers handle user-account creation and modification. Participating Web sites that have registered with .NET Passport use the .NET Passport Login server to authenticate users through the SSI service, the Wallet server to fetch user credit card information through the EP service, and the Kids server to support COPPA through the Kids Passport service. Microsoft keeps the .NET Passport account database and network servers in a secure data center.
What's in an Account?
A .NET Passport user account consists of four components: a .NET Passport Unique Identifier (PUID), a credential, a user profile, and a wallet. When a user creates an account, the .NET Passport system generates a PUID that identifies the account in the account database. The .NET Passport credential consists of the user's email address, which serves as a login name, and a password, which must consist of at least six characters. Users can optionally enter first name, last name, country, state, gender, birth date, and other personal information in the NET. Passport user profile, which Figure 1 shows. Users can use the profile to specify whether to release email address, name, or other personal information to participating Web sites. Users who want to use the EP service save their credit card numbers and billing and shipping addresses in the .NET Passport wallet.
.NET Passport user accounts are free. Registering for MSN Hotmail, personalizing MSN pages, or registering Windows XP through its Registration Wizard automatically creates a .NET Passport account. Users who haven't opened an account through one of these methods can create an account at .NET Passport's registration Web site (http://www.passport.com); participating Web sites often redirect nonregistered users to the registration site. The registration process uses the Secure Sockets Layer (SSL) protocol to protect the transmission of account information, then uses Triple DES (3DES) to encrypt sensitive data (e.g., password, credit card information) in the user database. Immediately after a user creates an account, .NET Passport sends the user an email message to verify the user's email address.
The SSI Service
With a .NET Passport account, users can sign in to a .NET Passport—participating Web site to access that site's services. The only necessary software is a Web browser: Microsoft Internet Explorer (IE) 4.01 Service Pack (SP2) or later or Netscape Navigator 4.5, 4.08, or later.
Participating Web sites display an official .NET Passport Sign In link, which Figure 2 shows. When a user clicks the link, the Web site uses the HTTP redirect method to redirect the user's browser to the .NET Passport Login server. The redirect includes a Login-server URL (e.g., http://login.passport.com/login.srf) followed by a query string. The query string starts with a question mark (?) and contains the Web site's language code, ID, return URL, and other data that the Login server needs. The Login server uses the ID and return URL to verify that the Web site is registered with .NET Passport, then displays a standard .NET Passport sign-in page. The Web site can cobrand this page, as Figure 3, page 32, shows. A cobranded sign-in page includes the participating Web site's logo, custom page layout, and other information. (Web sites can also embed the sign-in dialog box within their sites, a method that Microsoft calls inline sign-in.)
The user enters his or her .NET Passport credential (i.e., email address and password) in the .NET Passport Sign-in dialog box. If the user has signed in to .NET Passport before this particular Internet session, the browser remembers and automatically enters the user's email address unless the user selected the I'm using a public computer check box in the Sign-in dialog box, in which case the browser didn't record the email address. If the user selects the Sign me in automatically check box, the browser remembers the user's credentials so that the user won't need to enter a password manually the next time he or she signs in.
After entering the credential, the user clicks Sign In in the Sign-in dialog box. This action creates a user-authentication request, uses the HTTP POST method to post the credential information to the request, establishes an SSL connection with the .NET Passport Login server, then submits the user-authentication request and encrypted credential to the Login server. The sign-in page always communicates with the Login server through SSL, and the participating Web site doesn't receive the credential—only the Login server does.
The Login server then authenticates the credential against the .NET Passport account database and determines whether a database entry matches the credential. If a user enters the wrong password five consecutive times, the Login server locks the account for 5 minutes. After a successful authentication, the Login server extracts the PUID and appropriate user-profile information (according to the information that the user agreed to release to participating Web sites) from the database. The Login server creates five .NET Passport cookies, then writes them to the user's browser so that during the Internet session the server can identify the user's PUID, last sign-in time, a list of the sites to which the user has signed in, the user-profile information, and other user-provided information. The Login server encrypts the PUID, last sign-in time, and user-profile information in the cookies. The Login server then redirects the user's browser to the return URL. The Login server encrypts the PUID and shareable user-profile information through the Web site's .NET Passport—assigned site-encryption key, then adds the encrypted PUID and information to the query string that it sends to the return URL.
The Web site extracts the encrypted PUID and user-profile information from the query string, then uses its site-encryption key to decrypt the information. The Web site then creates and encrypts two site-specific .NET Passport cookies containing the user's PUID, sign-in time, and profile information and writes the cookies to the user's browser. The Web site uses these two cookies during the current session.
After a user successfully signs in to a participating Web site, the site displays the official .NET Passport Sign Out link, which Figure 4 shows. The participating Web site, not .NET Passport, implements authorization or user access to specific resources or services on the site. For security purposes, an authenticated sign-in to a participating Web site has a limited lifetime—4 hours by default. When the lifetime expires, the user must sign in again.
After a user has signed in to .NET Passport at a participating Web site, the user doesn't need to reenter the credential at other participating sites the user visits during the current Internet session, unless the other Web sites require users to reenter sign-in information as an additional security measure. The Login server silently verifies additional sites, determines from the cookies in the user's browser that the user has already signed in, updates the cookies, then sends the encrypted PUID and shareable user-profile information to the additional sites as I described earlier.
To sign out, the user clicks the Sign Out link. The sign-out function instructs the Login server to delete the .NET Passport cookies and initiates a script that asks each visited site to delete the site-specific cookies. All .NET Passport cookies are temporary. Therefore, even if the user doesn't sign out, the user's browser will delete the cookies when the user closes the browser. However, if the user enabled automatic sign-in, he or she must click the Sign Out link to delete the cookies.
No direct communication occurs between a participating Web site and the Login server. All communication takes place through the user's browser (i.e., through HTTP redirects, query strings, and HTTP POST).
Increasing Sign-In Security
.NET Passport calls the basic sign-in procedure I've described a standard sign-in. The standard sign-in contains a security risk: Cookie delivery is through clear text rather than HTTP over Secure Sockets Layer (HTTPS), so an intruder could capture the .NET Passport cookies as they pass from the Login server or Web site to the browser. The intruder could then impersonate a user within the Web site's defined authentication time window, thus performing a replay attack against the Web site. To avoid such a problem, .NET Passport 2.0 (the most recent version at the time of this writing) supports two secure sign-in methods: secure channel sign-in and strong credential sign-in.
Secure channel sign-in requires all authentication communication to use SSL to protect information transmission between the browser and the Web site and between the browser and the Login server. An intruder can't extract cookies from any captured encrypted information. In addition to the standard sign-in cookies, the Login server and Web site each create a secure HTTPS cookie that can't be manipulated, then compare the PUID in the secure cookie with the PUID in the regular cookies. If no secure cookie exists on the user's machine or if two PUIDs don't match (which would be the case if an intruder manipulated one of the standard cookies), the user must repeat the sign-in process.
Strong credential sign-in requires the user to enter a four-digit security key after successful secure channel sign-in. The user creates this security key in his or her .NET Passport account the first time he or she visits a participating Web site that requires strong credential sign-in; the key then becomes part of the user's credential. During key creation, the user must answer 3 out of 10 "secret" questions (i.e., questions not related to the user's credential or profile) and confirm the answers on a separate registration page before the .NET Passport system activates the security key. .NET Passport uses these questions and answers to confirm user identity in the event a user forgets his or her key.
The EP Service
Participating sites that offer the EP service include the official .NET Passport express purchase link, which Figure 5 shows, with the site's shopping cart information. After a user adds goods to the shopping cart, the user clicks the link to initiate the EP service. To protect the user's .NET Passport wallet, the Web site requires the user to reenter his or her password to sign in to the wallet. After wallet sign-in, the Web site redirects the user's browser to the .NET Passport Wallet server. The Wallet server displays the wallet information on the user's browser so that the user can select the appropriate credit card, billing address, and shipping address for the order. The wallet server can embed this information in the Web site's check-out page, as the fictitious example in Figure 6 shows. .NET Passport uses a Luhn algorithm to confirm the validity of the credit card number but doesn't perform credit card authorization.
To complete the purchase, the user clicks Continue or Buy Now at the bottom of the check-out page. The Wallet server then constructs an HTTP POST form containing the credit card information in Electronic Commerce Modeling Language (ECML) format (an industry-standard e-commerce schema that Microsoft, Visa, American Express, MasterCard, and other third parties developed). The Wallet server uses the Web site's site-encryption key to encrypt the information, posts the information to the return URL, and redirects the browser to the Web site's shopping-cart page. The Web site extracts the encrypted credit card information from the HTTP POST form, uses its site-encryption key to decrypt the information, then completes the appropriate payment authorization and shipping procedures. The EP service uses SSL to protect transmitted information.
Participating Web sites can use the .NET Passport EP service without providing the SSI service. However, sites that also use the SSI service can use the PUID as an index for shopping-cart status and order-tracking databases. Even Web sites that don't implement the SSI service must provide the Sign Out link to protect the user's wallet information.
Becoming a Participating Web Site
To enable .NET Passport on your Web site, you need to run .NET Passport objects on your Web servers and incorporate the .NET Passport functions (e.g., sign in, sign out) into the site. The free Microsoft Passport software development kit (SDK) contains the .NET Passport objects, a Passport Manager administration utility, a test Web site, and a sample Web site.
The Passport objects run on the Web server and handle all the .NET Passport service tasks, such as authentication, encryption, decryption, and reading and writing cookies. Passport Manager, which Figure 7 shows, lets you define your site's .NET Passport configuration (e.g., sign-in time window, forced sign-in, language ID, site ID, return URL, parameters for cookies and cobranding). You can also use Passport Manager to remotely configure Passport-enabled Web sites. The test Web site (current-login.passporttest.com) lets you run tests with your Web server. The sample Web site, Adventure Works, is a fictitious e-commerce site that uses SSI and EP; you can experiment with this site on your Web server, or you can access it over the Internet at adventureworks.passport.com.
You can download the SDK and related documentation from the Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/downloads/default.asp?url=/code/sample.asp?url=/msdn-files/027/001/644/msdncompositedoc.xml. Two versions of the SDK are available: Passport SDK 2.0 and Passport SDK 1.4. Passport SDK 2.0 requires XP or Windows 2000 Server, Microsoft Internet Information Services (IIS) 5.0 or later, and IE 4.01 SP2 or later. Passport SDK 1.4 supports Win2K Server, Windows NT 4.0 Server SP4 or later, Internet Information Server (IIS) 4.0 or later, and IE 4.01 SP2 or later. Passport SDK 2.0 includes support for secure channel and strong credential sign-in, advanced cobranding (e.g., flexible-layout cobranding, context-sensitive cobranding), the Platform for Privacy Preferences (P3P) standard for describing privacy policies in a machine-readable XML format, mobile devices, and XP. To use secure channel or strong credential sign-in and EP, your Web site needs an SSL certificate. You can obtain an SSL certificate from a Certification Authority (CA), which can be your organization (if it provides its own public key infrastructure—PKI—and CA service) or an external CA service provider, such as VeriSign.
The Passport SDK also supports non-Windows OSs (e.g., Sun's Solaris, Hewlett-Packard's HP-UX, Linux) and Web servers (e.g., Apache, Netscape, iPlanet). You can find more non-Windows support information in the Passport SDK documentation.
Microsoft provides two modes for using .NET Passport on your Web site: pre-production (PREP) mode and production mode. When you initially install the SDK on your Web server, your Web site operates in PREP mode. You can use this mode to test your development environment. First, however, you need to register your Web site with the .NET My Services Manager at https://www.netmyservicesmanager.com/wizard. When you do so, you receive a site ID and a site-encryption key that you install on your Web server. You then use Passport Manager to configure the site ID. After you complete your development and testing, you must apply to Microsoft to certify your Web site as a participating .NET Passport site. You also need to sign a .NET Passport agreement confirming that your Web site will comply with Microsoft's privacy and security policies.
When you've completed testing, you use Passport Manager to change from PREP mode to production mode. If you need to deploy the .NET Passport software on a server farm, you can use the Passport SDK setup.exe utility to record the installation on one server, then silently replay the installation on other servers.
The Passport SDK documentation provides step-by-step instructions about setting up a participating Web site and implementing the SSI, EP, and Kids Passport services. I suggest that you study this document before you develop your .NET Passport—enabled Web site. At the time of this writing, Microsoft charges participating Web sites an annual fee to use .NET Passport user-identification and -authentication services; Microsoft might also impose additional charges depending on a site's usage of the services (contact Microsoft for specific licensing costs).
Your Passport to Easy User Management
Microsoft's .NET Passport is a great example of how to centrally manage your Web site's user information and also provide an easy and efficient way for your users to access your site's services. To provide interoperability with other systems, Microsoft is implementing the Kerberos standard in .NET Passport user authentication. Although controversy over .NET Passport's privacy and security repercussions has been brewing in the industry, users don't seem to be holding back: At the time of this writing, several hundred million users have signed up to .NET Passport. Also at the time of this writing, more than 100 participating Web sites are in production mode and approximately 200 Web sites are in PREP mode. Vendors seem to be warming up to the idea that they can take advantage of this central user-identity management tool and focus their resources on developing e-commerce applications.
