This article will be the first in a short series on incorporating Windows Live ID authentication services into your web site.

Windows Live ID authentication services enables you to incorporate Passport authentication into your own Web sites. It also enables web sites to store personalized data and settings for customers by providing them with a unique ID for each Windows Live user who signs into your web site. The unique ID provided to the site is specific to the site in which the user is logging in and this protects the users credentials be delegating sign-in to the standard Windows Live ID sign in page. Users are additionally protected so that Windows Live ID profile data is not shared with the your web site. It also has the added benefit from the users perspective that one authentication mechanism, in this case Windows Live/Passport can be used for whichever site they visit (that incorporates it) and therefore they only have one username and password to remember and know that this information is safe.

So what does this all mean to you, the web developer? It means that by incorporating Windows Live ID your web site can now authenticate against millions of users who already use this service, if you host other Windows Live controls on your web site, you have a single sign-on to all these controls and it generally makes your job as a developer easier.  That is once you get past the initial hurdle.

So what is the initial hurdle and drawback of using Windows Live ID?  This can be broken into two steps :-

• If you’re used to using the authentication mechanisms that are basically provided out of the box by .Net 2.0 and upwards then you’ll have a slight change in thinking. Normally to capture a user and be able to store their settings and information you first ask a user to complete a form giving whichever information you need plus a username and password so that you can authenticate that user when they return and tie back all the settings etc. you have for them stored in your database. With Windows Live ID there is a slight change in thinking in that the user would first have to sign-in to Windows ID, then you check whether or not they are a new or already registered user from your database based upon the ID that is returned. If they are a new user then you would take them to your registration form for them to complete and tie the information they entered back with with the ID provided. No need for a username and password.
• The second step is that in order for this to really work using the current .Net 2.0 and upward authentication and information storage mechanisms (roles, preferences etc.) then you will need to program a custom Authentication Provider to tie everything together.

The first thing you need to know is how to actually use the Windows Live ID control within your web site. Fortunately this is fairly easy.
As with other Windows Live controls, the Windows Live ID control needs to reside within an iFrame on your web page. This iFrame then communicates back to your page through a shim so that your site can obtain the information returned.

So firstly the iFrame :-

<iframe id=”AuthLite” name=”AuthLite”
src=”http://login.live-int.com/controls/webauth.htm?appid=<%=AppID %>&context=<%=context %>“
width=”100px” height=”30px” marginwidth=”15″ marginheight=”5″ 
align=”middle” frameborder=”0″ scrolling=”no” style=”border-style: solid; border-width: thin;”>
</iframe>

Most of the information contained within this tag should be familiar to you, margins, height, width etc. The src attribute here is telling the iFrame to point to Windows Live ID authentication site and I’ve supplied a couple of parameters. The first parameter AppID is required by the Windows Live ID site, the second one context is optional.

You will notice from the src parameter that currently Windows Live ID only works with the internal “-int” authentication site. In order to use and test this you need to register with the internal site, create an internal passport account and also register your application. For more information on this please visit Connect.

The second optional parameter context gets passed back to your application from Windows Live ID and allows you to query it. This is useful in that it allows you to redirect a user to whatever page they were trying to access before they signed-in (or a page of your choosing) rather than just dumping the user back to your home page.

Here is the complete code for our sample Login page :-

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Windows ID Login Page</title>
</head>
<body>
    <iframe id="AuthLite" name="AuthLite"
        src="http://login.live-int.com/controls/webauth.htm?appid=<%=AppID %>&context=<%=context %>"
        width="100px" height="30px" marginwidth="15" marginheight="5"
        align="middle" frameborder="0" scrolling="no" style="border-style: solid; border-width: thin;">
    </iframe>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server" />
        <div>
                    <asp:Label ID="txt" runat="server" />
        </div>
    </form>
</body>
</html>

This is just a basic Ajax enabled page (optional, can be any aspx page) with the iFrame contained within it.

The code behind for this page :-

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using WindowsLiveAuthLite;

public partial class _Default : System.Web.UI.Page
{
    protected string AppID;
    protected string context;

  protected void Page_Load(object sender, EventArgs e)
  {
        WindowsLiveLogin wll = new WindowsLiveLogin();
        AppID = wll.AppId;
        context = "AfterLogin.aspx";

        HttpRequest req = HttpContext.Current.Request;
        string action = req.QueryString.Get("action");
        if (action == "clearcookie")
        {
            byte[] content;
            string type;
            wll.GetClearCookieResponse(out type, out content);
            HttpResponse res = HttpContext.Current.Response;
            res.ContentType = type;
            res.OutputStream.Write(content, 0, content.Length);
            res.End();
        }
        else
        {
            WindowsLiveLogin.User user = wll.ProcessLogin(req.Form);
            if (user != null)
            {
                txt.Text = "Your ID = " + user.Id;
                txt.Text += "<br> IsSane = " + user.IsSane();
                txt.Text += "<br> Token = " + user.Token.ToString();
                txt.Text += "<br> Context = " + user.Context.ToString();
                Server.Transfer(user.Context.ToString() + "?ID=" + user.Id);
            }
        }
  }
}

Again fairly basic, we create the protected fields for AppID and context that will be inserted into the appropriate placeholders within the iFrame before the call is made.
On Page Load we create a new Instance of WindowsLiveLogin that is found in the WindowsLiveAuthLite namespace (this is actually a .dll file that you will add to your bin directory. This dll is the shim that enables the iFrame to talk to your page, amongst other things).
We set the AppID and the page we wish to return to (context) then we query the Request object to see if the user has logged in or logged out.
If the user has logged out then we clear the cookie that was generated otherwise the user has logged in and we can gather some information, including transferring that user to the page that we require. Fairly simple stuff.

And that’s basically all there is to it.  The main information that you will be interested upon sign in is the user.Id property as this is the unique ID that identifies that particular user.  The user object actually exposes a couple of properties :-

When you run the code you will get a screen similar to above with a simple Sign-in button on it. This Sign-In button is your iFrame. When the user clicks on the Sign-In link they will be redirected to the standard Windows Live Authentication site :-

Where they will sign-in as normal. After signing in, the user will be redirected back to your site and you can process the result as per the code in the Page_Load method above.

In the code I’m transferring the user upon successful sign-in to another page. This other page simply displays the ID that is returned and also hosts a Windows Live Contacts control to show that the controls interact with each other (single sign-on). (I’ve blurred any names and my ID which is why the picture may look a bit weird).

And that’s essentially it, easy as that.  In the next part I will show you how you can actually use the Windows Live ID control with your own .Net 2.0 web site to create a new login process to capture user data, authenticate them and restore any settings you may have stored from that user.

Windows Live ID – Part 2 – Membership Provider
Windows Live ID – Part 3 – Putting it all together