Amid the growing rumble of attention surrounding Microsoft's .NET strategy, a clear voice has called out to lead the way to a world of shared services. That voice belongs to Passport. But is it the voice of hope or merely speaking in tongues?

Whether or not to integrate a service like Passport depends on several factors: the goals of your site, project timeline, available resources, and usability of the product itself. In designing the Microsoft^® Windows^® XP Developer Center, we decided to use Passport as the foundation of our authentication routine because of its rock-solid sign-in process and wide use among our core audience of MSDN subscribers. We also wanted to selflessly demonstrate Passport implementation for the benefit of our readers, because that's just the kind of people we are. Be aware, however, that our experience only covers version 1.3, with expanded functionality expected in upcoming versions.

Our conclusion? Because of our fairly unique setup, Passport took more time to implement than it should have. But in the long run, the confidence we've gained from having a secure and dependable auth routine offsets the up-front development time. Whether or not this will be the case for you depends on several factors. Before you make a decision, consider whether Passport fits your company's strategy (see the sidebar on "Why Passport?"), and then ask yourself the following questions:

1. Can I install new software on my Web servers?
The first and most important question in deciding whether to use Passport is how much authority you have over your Web servers. One of the first things you'll notice about Passport is that, like most shared services at this point, you'll have to put something on your host. In this case, that something is Passport Manager. Unfortunately, it can't be assumed that all developers have that kind of authority. In fact, the people most in need of a pre-developed auth routine are arguably small companies without the resources to develop their own, small companies which often use third-party ISPs for hosting. In this case, those companies are out of luck unless their ISPs can be convinced to integrate Passport.

In our case, we maintain our own server farm in-house, but unlike many Passport participants, we wanted to make the Developer Center a microsite off our primary destination. The only viable solution was to shunt all Passport-related processes to a separate box, which quickly complicated the architecture of the project. Since Passport requires a resolvable domain for authentication, we opted to create a subdomain (passport.devx.com) specifically for that machine. This also meant maintaining state using a complex series of redirects and cookies—not the simplest solution, but a versatile one.

A word of caution: if, like us, you use cookies for traffic management, personalization or other reasons, beware subdomains. Subdomains will eat your, well, dessert unless you take pains to specify the cookie domain. In Active Server Pages, use the .domain property. Also, be aware that Passport only looks at the domain you specified when you registered, so whatever machine you host Passport on, return to that machine when expiring your cookies. (See "Do I use cookies for maintaining state?" below.)

2. Do I need an authentication routine or a full ecommerce solution?
In addition to a Single Sign-In service for universal authentication, Microsoft also offers an Express Purchase service, formerly known as the wallet service. Since the Developer Center is not ecommerce, we didn't need to go there. But if you're thinking about it, give the Express Purchase Overview a look for more information:
http://www.passport.com/Business/

3. Do I need to capture any additional data about a member?
If you're reading this, chances are good you know our answer. We don't need much, but we do ask for a few details from our members, data specific to this project. Since Passport is built for verifying identity rather than capturing data, we augmented the auth routine with an additional registration process, which added another necessary layer of complication. You'll find that a user's Passport Profile offers the developer some nice extras for localization or personalization, but as most of these fields are optional, you'll need to do any required data capture on your own.

4. Am I using any Application Service Providers that require an additional sign-in?
Now it gets really tricky. It's not unheard of that most mid to large destinations will be outsourcing at least part of their site to a third-party service provider. In our case, we wanted to use Web Crossing for our discussion boards (http://www.webcrossing.com/). The problem is, they require a registration and login for every user. Unfortunately, we couldn't use the Passport ID because of privacy concerns. (See "Do I have a separate legal department?" below.) It took some finagling to work out a seamless registration/login process that coordinated Web Crossing, Passport and the Developer Center. If you were one of our early visitors, you know what I'm talking about.

Of course, this wouldn't have been an issue if everyone else were using Passport, which is the Passport vision in the first place. The good news is that same vision does suggest that sites can share the Passport ID, which means any two parties can collaborate to create a more seamless "orchestrated Web" experience (Microsoft's words, not mine).

5. Do I use cookies for maintaining state?
One of our biggest Gotchas turned out to be cookie expiration. Because of our hardware configuration and the fact that we were using multiple subdomains, cookie management turned out to be a bit trickier than normal. Also, Passport requires you to use a cookie expiration page to sign a user out of her Passport session, whether you add your own cookies or not. But the exact specs for the page are buried deep in the documentation. Reportedly this will be addressed in the upcoming update to their SDK in March. In the meantime, be sure to read through carefully and review the section in the SDK on expiring cookies. Here's the trick: in addition to wiping the cookie, you have to return a .gif file to indicate success. Take a look at the code we used:

<%@ Language="VBScript" %>
<%
Response.ContentType = "image/gif"
Response.Expires = -1
Response.AddHeader "Cache-Control", "no-cache"
Response.AddHeader "Pragma", "no-cache"

'[Cookie expiration code for Passport and YourCompany goes here]

%>

<!--#include file="checkmark.gif"-->

Especially note the ContentType and the final include file—both are required for Passport cookie expiration. Fortunately, the Passport team assures us that the upcoming revisions to the main site (http://www.passport.com) will include better docs and better samples. Code spelunkers will be out of luck but the rest of us should have an easier time of it after the redesign.

6. Do I have a separate legal department?
Sadly, one of our biggest barriers to implementing Passport had nothing to do with the software itself, but rather the licensing of it. On the upside, service fees are currently being waived so licensing is free. On the downside, the licensing contract is quite long and quite restrictive depending on what you're trying to accomplish. Unfortunately, it really needs to be so if Passport is to become as universal as Microsoft envisions.

What does this mean for the developer? First of all, despite what you may find on the Passport implementation checklist, request a licensing contract first and get the ball rolling as quickly as possible. Hopefully, it'll reach the bottom before you do. If you're a smaller shop or consultant and don't have legal assistance, read through the licensing agreement carefully and be prepared to invest a little more time and effort to meet all of its requirements, especially in the areas of privacy and customer service.

For us, this meant adding a unique "Alias" to member profiles for use with Web Crossing, since most Passport information is confidential and can't be shared with third-parties without getting user consent. Also, since the microsite concept doesn't fit the mold of a typical Passport participant, we had to renegotiate some of the details to make the contract more applicable to our situation. Word from Microsoft has it that the Passport team will release a new and friendlier contract shortly which should be more scalable for Microsoft and developers.

7. Do I have a separate marketing department?
Another couple of details that most developers would rather not contend with are co-branding and brand communication. Though your company can choose not to address either of these issues, Passport offers robust opportunities for co-branding your site on their sign-in pages, which carries your look-and-feel throughout the auth process. And following Microsoft Passport's Communication Guidelines is just the proper thing to do. I'm not saying we're doing it, necessarily; it's just the proper thing to do.

For more information:
Passport Co-branding Overview

Passport Communication Guidelines

8. What is my timeline?
You heard it here first: implementing a shared service can take a loooooooong time. Here's a short summary of the steps each participant must go through for Passport:

• Get the 15-page licensing contract. Forward to Legal (see above).
• Plan out the Passport implementation process, including any special hardware needs.
• Configure hardware in preparation for Passport installation.
• Put up placeholder pages for site URL and cookie expiration URL (these URLs are required fields in the registration form).
• Fill out and submit a three-page registration form for a temporary license and wait a day or two.
• After the registration is processed, receive the security certificate and installation instructions on a 3.5" floppy via overnight mail.
• Download the 3.2MB Passport SDK (v1.3 at press time).
• Install Passport Manager and the security certificate. You are now in TESTMODE.
• Develop and test the application.
• Fill out a new three-page registration form for a LIVE Site ID.
• If the licensing contract has been negotiated, approved and signed, then return it to Microsoft and continue. If not, raise thumb and sit. There's nothing else you can do at this point.
• After the licensing contract has been received and the LIVE registration processed, receive a new security certificate and installation instructions on a 3.5" floppy via overnight mail.
• Install the LIVE security certificate.
• TEST. TEST. TEST.
• Fix and test some more.
• Hold breath.
• Push OK.
• Exhale.

That's all there is to it!

The bottom line is, when your company starts using shared services, whether Passport or something else, plan ahead. The future of the web promises a new crop of complications, very few of which actually relate to coding. Hopefully, in time the hurdles will fall but until then, there's no predicting what a company may ask for (or how yours will respond).

9. Can I wait just a little while longer?
As of press time (meaning when I pressed the "Send" button in mid February 2001), the Passport Team is on the verge of releasing Passport 1.4, an interim update that puts into effect much of the feedback they've received from early adopters. Among the changes will be a more user-friendly Passport Manager install routine, and a redesigned Passport site that actually steps users through the implementation process. If you haven't noticed, the current site is, shall we say, immersive. In other words, you must completely immerse yourself in reams of documentation to find everything you need to know. The new site, which should be up by March 1, promises to make life easier in that regard.

How much of the above will be rendered obsolete by the upcoming changes remains to be seen. If discussions with the Passport Team are any indication, though, the stakes are high: if Passport is to become the universal log-in it aspires to be, security and privacy issues will remain a top priority, if not the top priority. As such, they will demand a premium on developer resources to ensure a high measure of reliability, consistency and quality.

Is the payoff worth it? Bottom line: it depends. If you're designing a straightforward Web app on a fairly plain hardware architecture, then Passport will have the higher-ups singing your praises. But if you have complex technical issues, then think carefully about the resources required, using the above points as your guidelines. If not, Passport's voice of hope may leave you babbling like an idiot.