A Word on Integration
The combination of a Live ID tailored to your URL and the control of a manageable login service makes Admin Center a powerful tool in the Windows Live arsenal. However, wielding that power requires some understanding of Live ID, and to a small degree, something referred to as Personalization.
|Figure 6. User Authentication Flow: Here's the data flow when authenticating with Live ID.|
Personalization refers to the act of identifying users when they log in, and delivering user-specific data or a change in the site experience based on that identification. If you are handling Windows Live authentication internally (not using Windows Live ID for authentication), personalization is a non-issue, because you already have the data you need upon authentication. However, a single sign-on model such as Live ID works differently, abstracting the consuming web site from the user's name and password. Instead of users passing their user name and password directly to a web site, their credentials are forwarded to the Live ID server. The server compares the data passed in with a separate Live ID account and, if valid, passes various other bits of data back to the consuming site. Figure 6
depicts this process graphically. The information sent back to your site is a combination of enciphered Live ID data and context data fed back through from the original sign-in page.
Without delving too deeply into the complexities of Live ID, it may help to familiarize yourself with the general steps a site should take to personalize an account. The process in Figure 6 depicts a login scenario with an existing Live ID account. One of the critical pieces of data received by the consuming web site from the Live ID servers when the user has been authenticated is a unique, pair-wise identifier, matching a user account with the specific website. This unique user ID (referred to here as the "UUID" from now on) is exclusive to a single user and a website; it never changes for the receiving site. No matter how many times an account's user name, email address, or password might change, the UUID stays the same for that website. However, the UUID contains no identifying characteristics; it is impossible to tell from the UUID just who is logging in. Therefore, it stands to reason that the consuming site will need to store a person's credentials and their corresponding UUID in a local data store to recognize a valid incoming user and show them personalized information. Getting to the point, all this leads to a specific registration scenario, which ameliorates this disconnected login process.
Most web sites offer a registration page for creating a new account. There, users can provide their personal information such as name, address, phone number, account credentials, likes, dislikes, favorite movies and so on. A web site using Live ID would do the same, storing the personal data locally and forwarding the user to the Live ID sign-in page. Using a context-specific variable in the Live ID SDK, the consuming web site would recognize that the UUID coming back from this user corresponds to the personal data it just saved.
|Author's Note: The Windows Live ID Web Authentication SDK is different than the Admin Center SDK. It provides the tools and utilities to incorporate Windows Live ID authentication into web and client applications.
|Figure 7. New Registration: Creating a new registration with Live ID is somewhat more complex.|
The UUID is added to the personal account, allowing the system to remember the user by UUID each time they come back to their site. See Figure 7
Personalization using Admin Center works almost exactly the same way, with a few extra steps in the beginning. The consuming site still needs to create an account and wait for the UUID; however, the registration page can also make calls to the Admin Center API to check for an existing user name and create new accounts. Conceptually the process is the same as the C# example you saw earlier. The end user first needs to choose a user name. The system will check to see if that name is taken and, if not, create the Live ID account. The system will still need to remember that the user is logging in for the first time, because the Admin Center API does not provide a method for extracting the UUID from a newly created member.
|Figure 8. Registration with Admin Center SDK: Here's the process that happens when you create a new registration with Live ID using the Admin Center SDK.|
shows the new registration process using Admin Center. At this point, the web site's login is complete. New users can create new accounts that look and feel like a local domain account, but that are actually fully functional Live IDs. What's more, the Admin Center API helped to make the process seamless, abstracting the user from the many different steps required to create the new member's account.
By this time, you should start to see some of the power behind Admin Center. There are far more features built into the API than this article covers, and you can do much more with the complete SDK than covered here as well. Remember that Admin Center is, at heart, a tool for web site federation. It's the glue between you and Microsoft that binds the features exposed by Windows Live with the unique experience of your own web site. For more information about Admin Center, Windows Live ID, Personalization, and other Windows Live features, refer to my book, Professional Windows Live Programming.