Identity management is a tricky issue for both developers and systems administrators. Within a single network, it's easy to determine which users are allowed access to specific systems or resources by querying a central directory service, such as Microsoft's ActiveDirectory. But in a widely dispersed network, or when customers or partners who aren't stored in a user directory require resources, the challenge is much more acute.

What to do? Many developers create home-grown solutions to this identity-management problem, often using relational databases tied together with the Lightweight Directory Access Protocol (LDAP). These systems can work, but they are difficult to construct, maintain, and secure. On the other hand, a trusted third-party identity service might be a more efficient tool for solving this problem.

One of the few such services available today is Microsoft's .NET Passport service. Already populated with millions of users—Microsoft claims that 160 million Passports have been issued—the service may be the ideal supplement or replacement technology for identity-management problems, particularly when those involve the general public.

Indeed, in many cases you may find it less expensive and more expedient to use Passport, rather than buy or develop your own server-based identity management solution...and given the rampant computer-security issues facing many businesses, it may even be safer to piggy-back on Microsoft's solution rather than worry about your own software being hacked.

Let's take a closer look at what Passport looks like to the end user and administrator. Then, we'll see how Passport can be incorporated into an enterprise solution.

User Perspective
From the end user's perspective, Passport is very simple: You sign into Passport once, using a unique e-mail address and password. Once your PC is signed in, different Web sites—including Microsoft's own Hotmail and MSN, but also other third-party sites—can detect that you've been authenticated to Passport, and they can learn some basic information about you, such as your real name and addresses, assuming that you've given that information to Microsoft when creating the Passport account.

Figure 1. Passport asks for certain core information once. If you provide it, that information is shared with any Web site or Web-based application that subscribes to Microsoft's Passport service. Click to enlarge.

There are many benefits to the end user, two of which stand out for specific mention: simplicity and consolidation. First, there is a single sign-on experience—the user only has to remember his or her e-mail address, and a single password. Going along with that, if the users change e-mail addresses or want to change their passwords, there's a single place to perform that transaction. By centralizing the ID process, end users may find the Internet experience more palatable (or less annoying) than being asked by many Web sites to provide the same user name and other information over and over again.

A second benefit is that there is a single trusted repository for the identity information: While consumers are naturally skeptical about giving out personal information in the Internet, it may be easier to trust a single huge publicly traded company, rather than trust dozens of smaller organizations.

From the perspective of the systems administrator or help-desk staff, the .NET Passport model also has a lot to commend itself. An identity-management infrastructure is a lot to maintain—why not let someone else do it? Microsoft already has the repository, the user interface, the tech-support infrastructure...all those little details, like handling a person's change of address or of password, retrieving lost passwords, and so on.

We can be assured that because .NET Passport is not only a business unit, but is also integral to other business units (like MSN and Hotmail), Microsoft will be continually working to improve the Passport software and service. From your company's perspective, your own identity-management system is likely to be a considerable cost center, and unlikely to receive great management attention (except when it fails). From that dimension alone, it also makes more sense to outsource the solution.

Single Sign-On

Figure 2. Passport's architecture has evolved to encompass Microsoft's MSN and Hotmail services, as well as to providing third-party authentication. Source: Microsoft Corp. Click to enlarge.

When launched in 1999, Passport was designed using a pure client/server architecture, but in 2001, Microsoft began to use the service as a flagship product for its .NET initiative, which uses peer-to-peer XML-based Web services (utilizing HTTP as the transport and SOAP as the mechanism for invoking services). Passport also uses browser cookies to handle authentication tickets, once a user is authenticated into the service. Today, Passport comprises quite a Web farm, with servers dedicated to a number of different tasks.

Fortunately, the complexity of the Passport architecture is hidden from third-party developers, who can choose one of two different services to work with under Passport: single sign-on (SSI), or express purchase (EP) which enables e-commerce using Microsoft's Wallet service.

For our purposes here, let's discuss the use of the SSI service—which obviously has applications far beyond e-commerce—using Microsoft's latest .NET Passport SDK, which is version 2.1. (See http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/885/msdncompositedoc.xml to access the documentation and bits for the Passport SDK for Windows, Linux, and Solaris—yes, it's multiplatform!)

There are three basic steps to incorporating Passport into an application, or into an enterprise infrastructure:

* First, you'll need to sign a .NET Services Agreement with Microsoft, which will give you a free preproduction site ID and encryption key, which you can use to prototype and build the site.

* Second, you'll need to add the appropriate Passport object calls to your ASP applications, and test to see if the application works. More about that in a moment.

* Third, you then apply to Microsoft to turn your preproduction site into a production site. That requires exposing your site or application on the public Internet so that Microsoft's Passport engineers can test it, as well as signing a contract with Microsoft for use of their service.

The cost is $10,000 annually to provision the service, plus a periodic compliance testing fee of $1,500 per company. There is no per-transaction charge.

The Passport Manager
I don't intend to discuss the details of implementing Passport within an application here because Microsoft offers extensive SDK documentation and code samples available on the site mentioned previously. Instead, I will outline the general process that your server code must go through.

Coding for Passport begins by including the Passport Manager object as a server-side object on any page that requires authentication. It's easiest to do that on ActiveServer Pages using the ASP Server.CreateObject method.

Once created, each page can make a call using the IsAuthenticated method to determine if the user has signed into Passport. If IsAuthenticated returns True, the user is authenticated; if the method returns False, you can redirect the user to Microsoft's Passport site for authentication, or offer to sign them into Passport directly from your site. You can specify optional parameters to increase the security according to your own site policies. For example, you can ask Passport to verify that the user has signed in using a secure method using encryption or digital certificates, as opposed to single unencrypted text passwords.

Once you've verified that the user has been authenticated to Passport, you can query the Passport Manager object to acquire the user's Passport Unique ID, a hex string. That's the only information that you can learn about the Passport user, without asking for additional permissions from the user; however, that PUID code can be used as the basis for your own access control list. In many cases, learning the PUID of the Passport user may be all your application requires to handle authentication, such as in an enterprise application.

However, if you want to learn more about the user, you can query the Passport Manager's HasProfile to determine if there is a profile associated with that PUID, and then use the Profile method to acquire specific data fields from the Passport server, such as first and last name, e-mail address, birth date, nickname, street address, occupation, gender, time zone, and whether the user has subscribed to Microsoft's Wallet payment service.

Makes it Easy
It's difficult to compare the simplicity of coding Microsoft's Passport Manager object within ASP to coding your own authentication management system, because there's really no comparison. While there are fees involved with the use of the Passport service, that's likely to be a lot lower than the cost of creating a stand-alone identity system. And faster, too: A Web developer should be able to add Passport to a Web site or ASP application within a week or two.

For more about the businesses uses of Microsoft's .NET Passport service, see the company's overview at http://www.microsoft.com/netservices/passport/. The consumer Web site is at http://www.passport.com.