.NET Passport is a Microsoft-operated service that provides Internet authentication for Web sites, no matter what kind of devices they use for access. It provides reliable Internet authentication and allows users to sign in once to access a variety of .NET Passport-enabled Web sites. In addition, users can save time by using Passport data when registering at new Passport-enabled Web sites. Developers don't have to build and maintain custom authentication mechanisms - Microsoft does the work.

Microsoft launched .NET Passport in 1999, and there are now more than 200 million .NET Passport accounts and over four billion authentications per month. As a precursor for future Web services, .NET Passport has allowed Microsoft to deal with problems of scalability, privacy, and security. Although it's sometimes been a rocky road, they probably now have a better idea of what to expect as they aggressively pursue other .NET Web services, such as the much-anticipated Microsoft .NET Alerts.

Microsoft has stated that .NET Passport will be their Web service authentication solution for .NET. However, there's been an unexpectedly high degree of reluctance on the part of traditional Microsoft partners to deploy .NET Passport, citing customer concerns about Microsoft "owning" their personal data and the complexities of implementation. Since Microsoft realizes authentication is a key component in a Web services world, they're taking positive steps to redesign the .NET Passport service and allay some of these fears.

Internet Authentication
Authentication is the process by which two parties exchange information to prove who they are. For example, most Web sites request that users register to access certain features of their site by creating a login name and password, which are known only by the two parties. When a user returns to a site, he or she must enter a username and password as proof of identity, after which access to the site is granted. Conversely, a Web site may present digital certificates to client Web browsers to prove that they are, for example, really a secure banking site and not a hacker spoofing the bank's identity.

Single Sign-In
Originally, .NET Passport was conceived of to help solve problems created for consumers and Web sites by the existence of individual Web site-maintained authentication schemes that require users to sign in to each site they visit. The basis for the single sign-in (SSI) solution approach was the realization that for every site a consumer wanted to interact with, he or she needed to enter the same information - name, address, phone number, and date of birth - and then create a username and password. Studies have shown that when Internet users have to remember a separate username and password for each Web site, many just use the same information for each site. This means when the password expires at one site, it needs to be changed at every site. The same problem is seen by users who move and then have to update personal information at every Web site they are registered with.

Passport SSI solves this problem by allowing users to enter a minimal amount of personal information (name, address, e-mail address, and birth date) as well as a password for the Passport account, all of which is securely stored by Passport. With the exception of the Passport Express Purchase service, any additional data a site wants to collect must be maintained by that site. To log in to a Passport-enabled site, users present credentials to Passport (via the SSI interface) and get an encrypted ticket cookie containing a Passport Unique ID (PUID) that's decrypted by the site and used to authenticate them. When registering at a new Passport-enabled site, users simply verify that they have a Passport. The site then uses the personal information stored by Passport to create the new account. Users even control how much personal information is shared with the site (the minimum being just the PUID). SSI also provides an additional level of security in that partner sites never have access to the users' authentication information (Passport username and password); they receive only the PUID from Passport.

Privacy Worries
There was a flurry of articles written about .NET Passport and concerns about privacy. This is a case where users can share what they feel comfortable sharing. .NET Passport stores a very limited amount of personal information. When users sign up for a Passport, they're asked for several pieces of personal information. However, the only information that is required to get a Passport is an e-mail address and a password. Although users are invited to provide additional information that can save them time when registering at other Web sites (for example, a .NET Passport-partner site could import address information from Passport as shipping information), they're not obligated to do so. Also, users can view and change these privacy settings at www.passport.com/memberservices.

The .NET Passport Privacy Policy - posted on Microsoft's Passport site, www.passport.com - states that Microsoft will not "mine, rent, sell, publish, or share user data beyond what the users choose." They also claim they won't create and sell reports based on customer data. In an attempt to prove their commitment to consumer privacy, Microsoft has become a participant in the Safe Harbor Agreement, a binding group of privacy agreements in the U.S. and Europe that requires .NET Passport-enabled sites to comply with the Platform for Privacy Preferences Project (P3P). Microsoft also contractually requires that all partner sites that implement .NET Passport have a posted privacy statement, and these sites are also encouraged to register with an independent privacy-assurance group such as TRUSTe. Whether or not to trust Microsoft to fulfill these promises is up to the user. As one of the world's largest providers of end-user software and services, Microsoft has more to lose than anyone if they choose to violate their customer's privacy and trust.

.NET Passport Security
Currently, .NET Passport relies on a cookie-based system, which Microsoft admits is not the ideal design and which they're working on improving. To address the potential vulnerabilities of cookie interception and misuse, Microsoft has taken several steps to improve security in the current version. These new security features of Passport 2.1 are:

• Cookie encryption: Passport encrypts cookies with site-specific keys to prevent access to user data. Cookies are encrypted using a Triple DES encryption algorithm with 168-bit keys. Each partner site has a unique encryption key, and keys can be rotated to decrease the likelihood of any one site's encryption key becoming compromised.
• Cookie timeouts: Passport has a default lifetime for the authenticated ticket cookies it creates, but sites can specify a shorter lifetime.
• Revalidation: Allows a site to verify that a user's e-mail sign-in name is a legitimate and monitored e-mail address.
• Secure sign-in: Requires that Secure Socket Layers (SSL) be used for all authentication round-trips and allows sites to require an additional security key for authentication.

While these changes have all been steps in the right direction, .NET Passport has a way to go. Fortunately, Microsoft has indicated that future versions will be based on the secure Kerberos v5 protocol, which will be described in greater detail later. The .NET Passport service will also likely be expanded to offer additional authentication mechanisms and security protocols to support digital certificates, smart cards, and even biometrics. The move to Kerberos technology alone will greatly increase the security of .NET Passport-enabled sites. In addition, .NET Passport will become one of many authentication services on the Internet that will compose a federated network of trust brokers based on forthcoming Web services security standards.

What Is .NET Passport Today?
.NET Passport v2.1 features a rather complex COM-based API, somewhat problematic implementation, and a cookie-based security system. It contains the following main components:

• .NET Passport Domain Login Server: Processes incoming user logins and issues Passport cookies, allows users to sign out and revokes cookies, and redirects new users to the registration server to create new Passports.
• .NET Passport Registration Server: Creates and manages user accounts.
• Passport Manager:
  Principal COM object installed on the partner site servers that provides sign-in logic and handles cookie encryption.
• Additional Passport objects: COM objects installed at the partner site that provide more specialized features, including Fast Authorization, manual encryption, and thread pooling.
• Kids Passport: Allows the extension of .NET Passport features to children under 18 only with the permission of an adult; the child's profile is then linked to the adult.

For more information on the .NET Passport SDK available today from MSDN, visit www.msdn.microsoft.com.

How It Works
A .NET Passport-enabled Web site redirects users to a separate .NET Passport Login server, which authenticates users and writes information to cookies stored on a user's machine. The authentication process is as follows:

1.   A user arrives at a .NET Passport- enabled site and requests an ASP page.

2.   During creation of the page, an instance of the Passport Manager object is created that sends a request back to the user's browser to check for valid Passport cookies.

3.   If these cookies can't be found (or when the site requires revalidation), the requested page loads with a sign-in link for Passport displayed. Otherwise, the sign-out link is displayed and the user is considered authenticated.

4.   The user clicks the .NET Passport sign-in link to begin the authentication process and is redirected to the .NET Passport sign-in page. Generated by the Passport Manager object, the URL for this redirect contains query strings that pass both the assigned site ID of the Passport-enabled site and a return URL used to return to the site after authentication.

5.   The Passport Login server checks whether the site ID and return URL are registered as partner sites. If so, a sign-in page is sent to the user's browser. If not, the authentication fails and the sign-in page is not displayed.

6.   The user enters his or her .NET Passport login credentials on the sign-in page and the information is sent, via SSL, to the Passport Login server.

7.   If the user can be positively authenticated by the Passport Login server, the server retrieves the user's PUID and Passport profile.

8.   The Passport Login server creates the following three cookies that are encrypted using the partner site's encryption key and site

ID: -Ticket cookie: Includes the PUID and a time stamp
-Profile cookie: Stores the profile information
-Visited Sites cookie: Stores a list of sites where the userbr
has signed in

Note: For security, partner sites use the PUID rather than
the login name to identify users. Authentication information isn't stored on the user's machine or at the partner site.
Profile information is only sent if this option has been requested by the user in his or her Passport account settings.

9.   These encrypted cookies are added as query
parameters to the redirected URL that's returned to the user's browser.

10.   The browser re-creates the encrypted cookies on
the user's machine and redirects the user back to the partner site, with the encrypted cookies passed again in the query
string.

11.   Passport Manager at the partner site uses the site's
encryption key to decrypt the cookies and extract the user's PUID and profile information, which can be added
to or updated in the site's own database.
Figure 1 depicts this authentication process.

 

It's interesting to note that in this version of Passport, no data is exchanged directly between the Web site and the Passport site. All data flows through requesting client.

Passport Manager

As we saw in the previous discussion, the Passport Manager object plays a crucial role in the authentication process. This COM-based object, installed on the partner sites' servers, is embedded as a server-side object once on each of the site's ASP pages. Passport Manager handles most of the Passport authentication logic with a minimal amount of site-specific programming in your ASP pages. The following shows the server-side ASP <OBJECT> tag used to embed the Passport Manager object:

<OBJECT RUNAT="SERVER"
ID="PassportManager"
PROGID="Passport.Manager">

You could also create the same object in ASP using VBScript as:

<% Dim oPassportMgr Set oPassportMgr = Server.CreateObject("Passport.Manager") %>

In addition to the Passport Manager object, each page must include the .NET Passport logo that users click on to sign in and out of the service. When an ASP page is loaded, and after the Passport Manager object has been instantiated, .NET Passport checks the user's computer for the cookies it needs to determine the user's sign-in state. Based on the user's state, the appropriate .NET Passport logo image is downloaded and created on the page (the location of the logo is dictated by Microsoft). If a .NET Passport cookie isn't found on the user's machine, the sign-in logo is displayed. Listing 1 demonstrates how the logo is created on the page. For an unauthenticated user, Passport Manager generates the following HTML to create the sign-in link and logo on the page:

Click here for the link

In this case, we've specified the URL returned after authentication as strReturnURL. If a return URL value isn't specified, the URL will be the default value set in the registry. In addition to the return URL, Passport supports a number of other parameters on the LogoTag2 method that allow developers to take more control over the login behavior of the Passport Manager, for example, forcing revalidation and specifying that an SSL connection must be used.

The Passport Manager object should always be instantiated in page scope. Instantiating this object at the application or session scope can cause the Passport Manager to lose state for individual users. Passport also offers a solution for high-volume Web sites that experience performance problems when instantiating the Passport Manager at page scope. The Passport Factory object allows you to create Passport Manager Objects from a pool to improve performance. In addition to Passport Manager and Passport Factory, the .NET Passport SDK also ships with additional COM objects, including Passport FastAuth, Passport Crypt, and Passport LookupTable, that support additional .NET Passport functionalities.

In an effort to extend Passport beyond the walls of Microsoft, the Passport Manager has been ported to Apache Web servers running on Linux, Solaris, AIX, HPUX, and FreeBSD. To learn more about these objects, see the Passport 2.1 SDK available from MSDN.

Where .NET Passport Is Heading
Following some of the most recent security enhancements, .NET Passport has become a fairly useful Internet authentication service in the B2C realm. However, its reliance on cookies, server-side installed components, and proprietary internal methods will prevent the current Passport 2.1 release from moving beyond end-user Internet applications. Also, as visionaries like Microsoft and IBM attempt to drive the world of Internet computing down the potentially beneficial (but mostly unfamiliar) road toward XML Web services, the functionalities of .NET Passport will certainly need to be expanded. Most importantly, .NET Passport will need to evolve into a true XML-based Web service in order to handle B2B authentication scenarios, where a Web server or service must authenticate against other Web services.

Indications from Microsoft are that upcoming versions of Passport will no longer be based on cookies and COM objects, but will have a true XML/SOAP Web services interface, which will make the service discoverable and easier to program against, especially for UNIX and Linux programmers. Implementation will go from a fairly complicated installation on your corporate servers to perhaps simply reading a WSDL file and being able to call the necessary Web services methods with the encrypted authentication information provided by your users. You'll even be able to accept tickets generated by a trusted, non-Passport authentication service. And best of all, implementing Web services security will follow XML-based standards. Other new initiatives Microsoft is embracing for its .NET Passport services include adding Kerberos encryption, making .NET Passport a federated service, and adopting new XML Web services standards and protocols.

Kerberos v5 Encryption
Kerberos is a method of securely establishing credentials in a distributed environment by using a third-party "trust broker." This protocol was originally designed by researchers at MIT to better implement security permissions on distributed networks and through secure firewalls. The foundation of secure authentication in Windows 2000 and Windows XP, Kerberos manages the trusts between client applications and service providers by means of a third-party Key Distribution Center (KDC). The KDC has two functions: it acts as both the Authentication Server (AS), authenticating users based on their supplied credentials and distributes ticket granting tickets (TGT); and as the Ticket Granting Server (TGS), distributing service access "tickets" and encryption keys. In the Kerberos world, clients present credentials to the KDC and in return get tickets that are used to access desired resources on a server. For Web services, the KDC functionality will be provided by .NET Passport or a .NET Passport Federated Partner that must conform to the forthcoming Passport Kerberos specification. Figure 2 shows the basics of how Passport Kerberos will work.

 

Federation
Last year, Microsoft announced its decision to federate .NET Passport, that is, to make the .NET Passport service interoperable with other authentication services. Federation is a newly emerging concept in Web services that seeks to promote trust relationships between a variety of authentication infrastructures, such as Kerberos, Public-Key protocols, and Security Information Management (SIM), that are already widely used both in internal corporate networks and on the Internet. Federation will allow .NET Passport-based Web services to accept credentials from any network that has a trust relationship with .NET Passport, potentially expanding the scope of Web services to environments such as corporate intranets. The next release of Passport will support a version of the Kerberos v5 protocol, which will lay the groundwork for federation. There are plans to make federation a reality in 2003, pending the adoption of newly proposed XML Web Services Architecture standards.

Web Service Standards
The overall Web services security model that .NET Passport is moving toward is being defined by Microsoft- and IBM- sponsored specifications. Built on the Simple Object Access Protocol (SOAP), these protocols will provide an additional, modular layer that will improve the utility of XML Web services in the enterprise by providing standards for message transport, reliable messaging, discovery, security, and trust. The foundation security specification is WS-Security, which defines an end-to-end message security protocol that supports a wide variety of security models. Following this specification, which is currently in the beta-release stage, there will be other protocols that further clarify how federation works, including WS-Trust, WS-SecureConversation, WS-Authorization, and WS-Federation. As Microsoft is a major proponent of these standards, you can be sure that .NET Passport will follow them.

The Next Version of .NET Passport
While many of these Web services-based improvements will not likely occur until 2003, expect to see updates to .NET Passport in the September release of the SDK. This release will include support for .NET Passport Kerberos as well as a Passport Client Runtime that provides rich client support for Passport Kerberos. To sign up for .NET Passport service for your Web site, go to www.netmyservicesmanager.com, which has a wizard that can walk you through getting an ID and setting .NET Passport up on your site. For the .NET Passport SDK, go to http://msdn.microsoft.com/netmyservices and go to the download center. To learn more about .NET Passport and .NET My Services, check out www.gotdotnet.com and www.passport.com.