Windows Live ID Adoption Solution in Microsoft.com

(This is the first blog post from the Test Team that is working on the new Microsoft.com portal site. Testing is critical in the process of getting new code into production. Authentication and authorization can be especially interesting issues to test.)

Passport has long played the role of the single sign-on experience as the authentication service across web sites in Microsoft.com. The passport team plans to turn off support for Passport Manager 2.5, aka PPM2.5 and replace it with the newer version of the Windows Live ID Relying Party Suite, aka RPS. RPS4.0 supports IIS running in 32bit mode. Soon we will have RPS4.5 supporting IIS running in 64bit mode.

 As a provider of authentication and authorization services to Microsoft.com portal site, Portal Secure Team encountered a series of issues upgrading from PPM2.5 to RPS4.0 and RPS4.5.

Here are some of the issues we are facing:

1. How do we enable adopters to minimize the change of their code for such migration?

2. How do we handle two different sites A and B using the same Site ID and same cookie encryption key (CEK)? How does the passport handle the redirects when user signed into site A that is considered invalid due to security level or time window or even different version of passports?

3. How do we handle two different sites A and B using different site ID or different encryption key (CEK)?

4. How do we handle two different sites with site A running PPM2.4 and site B running RPS? RPS does not recognize PPM cookies or vice versa.

5. How do we allow adopters to use PPM when they are able to maintain good working condition when the switch happens? How do we provide the seamless transition?

6. How do we handle the redirect to our authentication page when user is not signed in to Windows live ID in the scenarios described above?

The team has built a Passport Authentication Library (PAL) to ease the pain of the Windows Live ID adopters. Basically, the PAL has wrapped the RPS APIs that are useful in our adoption scenarios and created an HTTP module to provide a unified authentication solution for Microsoft.com.

Below is an example of the code snippets to show that we have handled a lot of implementation behind the scene required by RPS and provide adopters with similar look and feel of the old implementation.

// Before PAL:

using System.Web.Security;

...

PassportIdentity pi = User.Identity as PassportIdentity;

if (pi != null && pi.IsAuthenticated)

{

      int puidLow = (int)pi.GetProfileObject("MemberIDLow");

      int puidHigh = (int)pi.GetProfileObject("MemberIDHigh");

// ...

}

// After PAL:

using Microsoft.MSCOM.MemberServices.Passport;

...

PassportUser pu = PassportUser.Current;

if (pu != null && pu.IsAuthenticated )

{

      PassportID puid = pu.Puid;

      // ...

 

Here is a peek into one of the complex business scenarios we face:

 

Scenario: User Access A Secure Public page

 

Frequently, Enterprises tend to get stuck with implementation of new releases and new innovation of the software. It is never an easy task to upgrade server side components. However, the PAL provides an example of how to bridge the gap with less pain in such processes. We have gained tremendous experience in making such efforts.

Comments

• Anonymous
  November 20, 2006
  Thank you, this really helped me a lot to migrate my site to PAL 4.0.