URL Rewriting Revisited

For many of our scenarios, URL Rewriting works very well.  Since my last blog post, Azure has added the URL Rewriting module to the web role, so, for many scenarios, this is a great solution.

Where we ran into issues in our scenario is that we did not know the type or number of pages that could be created in advance.  If a tenant creates a PageZZZ url, where do we route the request?  In many scenarios, you know the set of pages in advance, so this isn’t an issue.  

Enter the HTTP Handler

Our first attempt at handling this issue was to implement an HTTP Handler.  We used the MVC pattern and the implementation was surprisingly straight forward and easy.  The hardest part was getting the web.config exactly right.

Because of some other things we were doing, we ended up with quite a bit of code in global.asax. We also ran into a requirement to host URLs that didn’t have an extension. It became difficult to work around IIS’ “helpfulness” and we had a lot more code than it felt like we should.

HTTP Module to the Rescue

Having built a number of ISAPI extensions and filters, I was not looking forward to implementing an HTTP Module. Fortunately, IIS has come a long way and the module really wasn’t any harder than the handler.

The module cleaned up (ie removed) global.asax.cs. The module also gave us a very nice encapsulation and deployment story.

Later in the process, we decided that we wanted to instrument our code and log some results to Azure tables.  The module made this easy to do as we didn’t have to modify any page level code.  You could accomplish the same thing from global.asax, but it wouldn’t be as nicely encapsulated or as easy to reuse.

I have never been a huge MVC fan, but after implementing an HTTP Module using MVC, there are some problems that are much easier to solve and the code is much cleaner.

Azure Peculiarities

We are storing all of our data in Azure Tables (anxiously awaiting the next version of SDS).  One of the key things our code does is break the URL into pieces (i.e. Tenant ID and Page ID).  Once it does this, it checks an Azure table to determine if the page exists (remember, we don’t know the set of pages in advance) and if we have rights to the page.  Most of us are used to case-insensitive URLs and Azure tables are case-sensitive.  Another issue is that many pages have an extension (i.e. rss.xml).  Azure doesn’t like special characters in the key or the search fields, so this needs to be handled.  Obviously it’s not difficult, if you know the issues in advance.

We chose to store the Tenant ID and Page ID natively – in our case using proper case and allowing file extensions.  The partition key is the escaped, lowercase of the Tenant ID and the row key is the same for the Page ID.

We embedded these rules in the SitePage class and created a constructor that takes Tenant ID and Page ID.  We then use the partition key and row key as our parameters.  The code looks something like this:

We decided on this approach as we use the entity classes in multiple layers of the app.  This approach gives us good encapsulation and forces the user making the call to pass the right parameters.  There may also be scenarios in the future where we don’t want to enforce these rules.

Mapping the Request

The HTTP Module also gives us the best of both worlds when handling a request.  Depending on the type of request (retrieved from the Azure table), we can use URL Rewrite to send the request to an existing ASPX page or we can invoke one or the custom handlers to process the code.

Our original intent was to process all of the requests with custom handlers and this worked really well for read pages.  When it came time to build forms for updating, the ASPX model really made development and debugging easier.  Once debugged, if we choose, we can move the code into a custom handler and change the mapping in the table.

Performance of the HTTP Module

We had plans to implement caching for our June release, but decided to postpone the feature to a later release as our performance was more than adequate.  I was amazed at how few lines of code it took to build a custom controller.  The IIS team did a great job building a platform.

Packaging the Sample

I’m in the process of packaging a simple HTTP Module that handles a multi-tenant mapping strategy and implements custom asynchronous logging to Azure tables.  We have a June 30 ship date, so it may take a couple of weeks for me to get the sample cleaned up and posted.

Program.cs

This code will work from a web project, or you can just put it directly into an IIS folder.  I have the realm set to localhost/default.aspx, so adjust the instructions as necessary to point to the correct URL.  All you need is the WebForm page and the code-behind file.  The code doesn't use Geneva, so it will work on a normal ASP.NET 3.5 install.

Step 1 - create a web project and delete everything from default.aspx except the first line.  Add a ValidateRequest="false" attribute to the Page directive.  It should look similar to this

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

Step 2 - Paste the following code into the Page_Load event

if (Request["wresult"] == null)

{

    Response.Redirect("https://{{Account}}.accesscontrol.windows.net/passivests/LiveFederation.aspx?wa=wsignin1.0&wtrealm=https://localhost/default.aspx&whr=https://login.live.com");

}

else

{

    Response.Write(Request["wresult"]);

    Response.ContentType = "text/xml";

}

Make sure to replace {{Account}} with your ACS account name.

This code will automatically redirect you to the Live Federation page where you can login with your Live ID.  Once you successfully login, the code pulls the SAML out of the wresult form variable and displays it as XML.  This allows you to quickly test changes to ACS.

If you would like to control the output, you can replace the two lines of code that display the SAML with the following code:

XmlDocument d = new XmlDocument();

d.LoadXml(Request["wresult"]);

Response.Write("<table border=1>\n<tr><td>AttributeName</td><td>Value</td></tr>\n");

foreach (XmlNode node in d.GetElementsByTagName("saml:Attribute"))

{

    if (node.Attributes.GetNamedItem("AttributeName") != null)

    {

        Response.Write(string.Format("<tr><td>{0}</td><td>{1}</td></tr>\n", node.Attributes.GetNamedItem("AttributeName").Value, node.InnerText));

    }

}

Response.Write("</table>\n");

In my case, the display looks like this:

AttributeName	Value
role	Admin
emailaddress	user@foo.com
name	user@foo.com

This is NOT a secure implementation - for that, use Geneva.  However, this will help you quickly validate if you're getting what you expect from the Live ID Federation page.

In a previous post, I implemented a few of the Azure Table REST APIs as a starting point for testing without having to use the Storage Client sample that ships in the Azure SDK.  The Azure Storage REST API is documented here.  Instructions and the updated code are at the bottom of this post. 

Version 2

In this version of the code, I added support for all of the Azure Table REST API as well as the Azure Blob API (minus the blob chunking).  Based on the docs, the queue API looks very similar to the Blob API, so it shouldn't be difficult to implement.

For the entity insert and update table methods, I chose to use a simple entity class and use reflection to convert the properties into the appropriate XML payload.  I liked this better than using a dictionary type collection or hard coding the implementation.

My original goal was to have all of the REST functionality encapsulated in the RESTHelper class.  After trying that for a while, I decided that there were enough differences to warrant different implementations for blobs and tables.  The account, secret, SharedKey generation, and exception handling are shared, but the signature creation and request execution are separate implementations.

To make the logic a little simpler, I implemented a “command” parameter in the Blob RESTExec method.  For most requests, this is the HTTP Method, but for some requests additional headers have to be added.   This seems simpler than using a combination of URI and Method or adding another parameter.  There is code that uses the Command parameter to modify the URI, set the HTTP method, and add headers as appropriate.

Caveats

·         The code still only works on Azure Storage, it does not work on development storage (see my reasoning in the previous post).

·         I have only implemented / tested with string data.

·         The updated code is sample code quality with limited error handling, testing, and comments, so it’s only appropriate for experimentation and as a starting point. 

·         The code is still all in one file, which is easy to post and get running the first time, but not a best practice for a real app.

·         You still need to update the account / secret information in the RESTHelper class.

Feedback

One of the Azure developers clarified a comment I made in my original post about including query strings in the signature.  In his words:  “For blobs, one must include only the ‘comp’ query parameter if it exists, not the entire query string.  The ‘comp’ query parameter identifies a sub-resource and hence is integral to the resource being operated on by the request.  This is the reason to include it in the signature.  Table storage doesn’t use the ‘comp’ query parameter, so we don’t include it there.  This can be simply said as “Include the ‘comp’ query parameter into the canonicalized resources if it exists.”  This probably holds good for all services.”  This makes sense and helped me when I was implementing the Blob API.  Thanks Rags!

Another suggestion was to use the .NET ATOM classes to process the Table results.  I tried this, but chose to stick with direct XML instead.  If you choose to use the Table REST API directly, you might want to look into the syndication classes.

Learnings

·         Make sure to wrap all of your web calls with using or explicitly close the connections.

·         Azure Blob containers don’t appear to support capital letters.

·         Getting the signature exactly right is still the hardest part.

o   I now understand why the API forces resources and headers to be canonicalized.

·         The REST API is great for viewing arbitrary tables without knowing the structure in advance.

Using the Sample Code

Create a new console application named AzureStorageConsole, then replace the code in Program.cs with the code attached below. 

Change the “accountN” and “secretN” references to your Azure credentials.  I decided to embed the storage account information in the code vs. reading it from a config file.  This implementation uses a helper class to allow you to specify the account in the constructor, which makes it easy to use different accounts simultaneously.

Note that you do not have to install the Azure SDK to use the sample code.  A vanilla install of .NET 3.5 will work.

Program.cs

Development Storage

Note that this code has not been tested on development storage, only on the Azure services.  I decided to quit using the development storage a couple of months ago and now only use Azure storage.  My reasoning was simple:  Azure storage is very similar to development storage, but it is not exact.  I didn’t want to have to understand or debug the nuances.  I also didn’t want to have to migrate the data every time I did a build.  My experience also told me that it was very important to understand the performance of the data subsystem.  Identifying data performance issues early is a lot better than staying up all night putting hot fixes into your latest release, and running the storage services remotely with the web server local is just about a worst case scenario.  As a remote member of the team, it is also much easier to share code that talks to the same storage.  You don’t have to worry about synching your tables every time you want to jointly debug an app.  Your mileage may vary, but I am very happy with the decision.

The Code

My goal for this exercise is pretty simple.  I want to list all of the tables in the storage account and I want to display all of the data within any one of those tables.  While writing the code, I decided that I want to be able to limit the queries with a “where” clause (mainly because it was really easy to do).  With the goal of keeping it simple, I’m delaying table create and delete and entity insert, update, and delete until later.

According to the documents, in order to get a list of tables, all one has to do is use HTTP GET to call https://myaccount.table.core.windows.net/Tables making sure to replace myaccount with the correct storage account.  After some more digging, it turns out that you have to add some headers to the request, including a signature header.  Figuring out exactly how to construct those headers was the only difficult part of the exercise.

Here is a walkthrough of the code.

Step 1 - Create the web request

// Resource = “Tables”

// _Account = your Azure Storage Account

string uri = @"https://" + _Account + ".table.core.windows.net/" + Resource;

HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(uri);

request.Method = "GET";

request.ContentLength = 0;

Step 2 – Add a date header to the request

request.Headers.Add("x-ms-date", DateTime.UtcNow.ToString("R", System.Globalization.CultureInfo.InvariantCulture));

Step 3 - Sign the request

For a table, you need to use this Canonical form:

VERB + "\n" +

Content - MD5 + "\n" +

Content - Type + "\n" +

Date + "\n" +

CanonicalizedResources

My first reaction to this was – huh?  I pieced together the following code that implements the above.

// Verb

string signature = "GET\n";

// Content-MD5

signature += "\n";

// Content-Type

signature += "\n";

// Date

signature += request.Headers["x-ms-date"] + "\n";

// remove the query string

int q = Resource.IndexOf("?");

if (q > 0) Resource = Resource.Substring(0, q);

// Canonicalized Resource

// Format is /{0}/{1} where 0 is name of the account and 1 is resources URI path

signature += "/" + _Account + "/" + Resource;

Note that for the table storage signature, you remove the query string from the resource but for blob storage you do not.  This is documented in the API, but I missed it and wasted a lot of debug cycles.

Step 4 - Hash the signature with the secret and add the result to the SharedKey header

Replace _Secret with your Azure account secret.  Table Storage also supports SharedKeyLite, but Blobs don’t, so I decided to stick with SharedKey.

// Hash-based Message Authentication Code (HMAC) using SHA256 hash

System.Security.Cryptography.HMACSHA256 hasher = new System.Security.Cryptography.HMACSHA256(Convert.FromBase64String(_Secret));

// Authorization header

string authH = "SharedKey " + _Account + ":" + System.Convert.ToBase64String(hasher.ComputeHash(System.Text.Encoding.UTF8.GetBytes(signature)));

Step 5 - Getting the results

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())

{

using (System.IO.StreamReader r = new System.IO.StreamReader(response.GetResponseStream()))

{

string xml = r.ReadToEnd();

int ret = response.StatusCode; 

}

}

Step 6 – Processing the results

According to the Azure Table API document,  “The Query Tables operation returns the list of tables in the account as an ADO.NET entity set, which is an Atom feed.”  The documentation shows the XML results returned.  In this case, all we care about is the “d:TableName” repeating element.

if (ret == 200)

{

XmlDocument doc = new XmlDocument();

doc.LoadXml(xml);

XmlNodeList nodes = doc.GetElementsByTagName("d:TableName");

Console.WriteLine("Tables in Account: " + _Account);

foreach (XmlNode n in nodes)

{

Console.WriteLine(n.InnerText);

}

}

else

{

Console.WriteLine(xml);

}

Console.WriteLine();

That’s all there is to it.  Once you get this code working, it’s pretty easy to modify the URIs for other calls.  Simply change the Resource.  Here are some examples queries:

Customers – returns all rows from the Customers table (assuming that table actually exists)

Customers?$filter=state eq TX

Songs?$filter=rating ge 3

The general format to retrieve data from a table is “mytable$filter=<query-expression>”.  More information is available here.

The following code will process the results from the table, displaying each field of each row.

if (status == 200)

{

XmlDocument doc = new XmlDocument();

doc.LoadXml(xml);

XmlNodeList nodes = doc.GetElementsByTagName("m:properties");

// process each row

foreach (XmlNode n in nodes)

{

// process each column

foreach (XmlNode n2 in n.ChildNodes)

{

Console.Write(n2.Name + ": " + n2.InnerText);

}

Console.WriteLine();

}

}

Sample Console App Code

If you create a new console application named AzureStorageConsole, you can replace the code in Program.cs with the code attached below.  You will also need to change the “accountN” and “secretN” references to your Azure credentials.  I decided to embed the storage account information in the code vs. reading it from a config file.  This implementation uses a helper class to allow you to specify the account in the constructor, which makes it easy to use different accounts.  Lastly, you will need to replace the Customer table queries with existing tables in your storage account.

The next steps are to add support for creating and deleting tables as well as insert, edit, and delete capabilities to individual tables.  I am also going to play around with the REST APIs for Blobs and Queues.  They appear to be quite a bit simpler than the Table API.

Program.cs

As long as you have Internet connectivity, these services are available to your application anywhere.  I have a hosting account at GoDaddy and wanted to check the feasibility of storing data in Azure while hosting outside of the Azure data center.  

To accomplish this, I simply copied the Lib folder from the Azure Storage Client sample in the Azure SDK.  This contains all of the helper functions that make accessing Azure storage from .Net simple.  To help me keep things clear, I renamed the project and the folder StorageLibNoDepend.

Next I created a console solution in Visual Studio and added the StorageLibNoDepend project to the solution.  A quick compile verified that everything works.

Now to break it …

I removed the reference to Microsoft.ServiceHosting.ServiceRuntime from the StorageLib project and let the compiler find the dependencies.  The first dependency was a using statement in StorageAccountInfo.cs (it turns out that all of the changes are in this one file).  All of the other changes had to do with reading configuration settings from the Azure config service rather than the config files.  I simply deleted these large blocks of code (5 or 6 of them) and the system compiled.

Next I added an app.config file with the following settings:

<configuration>

  <appSettings>

    <add key="AccountName" value="youraccountname"/>

    <add key="AccountSharedKey" value="yourkey"/>

    <add key="BlobStorageEndpoint" value="https://blob.core.windows.net"/>

    <add key="QueueStorageEndpoint" value="https://queue.core.windows.net"/>

    <add key="TableStorageEndpoint" value="https://table.core.windows.net"/>

    <add key="UsePathStyleUris" value="false"/>

  </appSettings>

</configuration>

You will need to update the AccountName and AccountSharedKey values appropriately.

Next, add a reference to the StorageLibNoDepend project to the console application.  Also add the following using statement to the console app.

using Microsoft.Samples.ServiceHosting.StorageClient;

Paste the following code into the Main method of the console application.

BlobStorage blobStorage = BlobStorage.Create(StorageAccountInfo.GetDefaultBlobStorageAccountFromConfiguration());

foreach (BlobContainer b in blobStorage.ListBlobContainers())

{

Console.WriteLine(b.ContainerName);

}

Console.ReadLine();

When you press F5, the application should run and display a list of all of the blob containers in your account.

With this library, you can use Azure storage from any application, not just an app running in the Azure hosted environment.  So far, the performance has been quite good as has the availability of Azure Storage.  I currently have three different applications – a web app hosted at GoDaddy, a web app hosted in Azure, and a console app – accessing the same database tables – no replication, synchronization, or conflict management to deal with! 

Obviously, there are some performance implications to this model, but so far, the performance has been very good.  The key is limiting the amount of data returned whenever possible.  The possibilities enabled by this type of cloud database are very exciting and the Azure Storage Library makes it very simple to consume.

We are building an Azure-based, multi-tenant web prototype and came across an issue that is worth considering.  In particular, how do you address the website based on your tenancy?  We identified four ways to accomplish this – I would be interested if you know of other good techniques.

The first one that came to mind was to use a sub-domain to specify the tenant (tenant1.azureapp.com, tenant2.azureapp.com, etc).  I have done systems like this in the past and it worked very well.  However, Azure complicates things a little bit.  Currently, Azure does not give you a specific IP address, but rather gives you an FQDN like coolapp.cloudapp.net.  I was not able to figure out a way to automatically map all hosts to this address as the A record is expecting an IP address.  Assuming I didn’t miss something, this means that you have to create a CNAME DNS entry for each tenant.  This isn’t a big deal for a “small” number of tenants, and there are use cases where the CNAME will actually be in the tenant’s domain.  However, for a “large” number of tenants, this seems like additional management and could perhaps cause DNS issues (imagine 10K CNAMES in a domain).

The next option I explored, and ultimately decided on, was to use the tenant name in the url (coolapp.cloudapp.net/tenant1/default.aspx, coolapp.cloudapp.net/tenant2/profile.aspx, etc.) 

Another option thrown out was to map the tenant based on the Live ID.  This became very complex in scenarios where a Live ID was valid in multiple tenants, so it didn’t work for us, but this could be a good option for some.

Another option was to specify the tenant name or ID in the query string.  This works fine, but didn’t seem as user friendly as the first two options.  It turns out that this is exactly how we are implementing it under the covers, but I wanted to provide a more user friendly method.  This is by far the easiest implementation.

URL Rewriting

The option I ended up choosing basically maps a URL from coolapp.cloudapp.net/tenant1/default.aspx to coolapp.cloudapp.net/app/default.aspx?tenant=tenant1.  The initial plan was to use the IIS URL rewriting module to implement this feature.  Unfortunately, Azure doesn’t currently run this module, but since this is a commonly requested feature, hopefully it will make it into a future version of Azure.

There are several page frameworks, including the ASP.NET MVC framework that provide URL rewriting capabilities.  It is also easy to implement URL re-writing in code.  In the Application_BeginRequest method in global.asax, use the HTTPContext.Current.RewritePath method to do the mapping for you.

Our logic is pretty straight forward:

If the request begins with “/app/”, redirect to “/”.  I don't want people accessing our app pages directly, which gives us the freedom to version and change the mappings later. 

If the request is in the root web folder or in the images web folder, ignore it.

Otherwise, extract the tenant id and the page from the URL.  The URL is in the format coolapp.cloudapp.net/{tenant}/{page}.  Make sure to deal with the coolapp.cloudapp.net/{tenant}/ request.

Look the tenant id up in a database, and, if the id is valid and the page exists in the app folder, map to /app/{page}?tenantID={tenant}

If the tenant id is not valid or if the page doesn’t exist, just let the request pass through and IIS will return a 404 error.

Two Things I Learned

In general, this was a pretty simple task to implement.  It isn’t fully tested yet, but so far, I’ve only hit two snags.

The first, mentioned above, is to make sure to explicitly deal with the coolapp.cloudapp.net/{tenant}/ URL. 

The second, and maybe there’s a way to fix this, is to adjust the form Action property to point to the friendly URL instead of the actual URL.  I used this piece of code in the Page_Load event of all of the ASPX files in the /app/ folder:

form1.Action = "/" + Request.QueryString["tenantID"] + Request.Path.Substring(Request.Path.LastIndexOf("/"));

In a follow up post, I modified the example to require no code by using the Geneva provider and the standard ASP.NET authorize configuration.

In this example, I am going to show a couple of different ways to implement an Admin role using ASP.NET and the Geneva provider.

After you get the second sample running correctly, add the following to the end of the web.config file just before the configuration close tag.

<location path="admin">
   <system.web>
      <authorization>
          <deny users ="*" />
          <allow roles ="Admin" />
      </authorization>
   </system.web>
</location>

This config param overrides the main authorization config and restricts access to all files in the admin folder to users in the admin role.

To test this, create a new folder named Admin.  Copy Page2.aspx and past into the admin folder.  Rename Page2.aspx to default.aspx (in the Admin folder).

Now you need to add your user id to the admin role.  There are a few different ways to do this.  One way, which *should* work (in other words, I haven't tested it) is to create an ASP.NET role provider, create the Admin role, and add your Live ID to the Admin role.

Geneva also provides a way to achieve this.  Paste the following code into global.asax.cs:

void WSFederationAuthenticationModule_SessionSecurityTokenCreated(Object sender, SessionSecurityTokenCreatedEventArgs e)

IClaimsIdentity id = (IClaimsIdentity)e.SessionToken.ClaimsPrincipal.Identity;

if (id != null && id.IsAuthenticated && id.Name.EndsWith("@microsoft.com", StringComparison.OrdinalIgnoreCase))

id.Claims.Add(new Claim(

System.Web.Configuration.WebConfigurationManager.AppSettings["RoleClaim"].ToString(),

"Admin"));

The SessionSecurityTokenCreated event is a new Geneva event that gets called when the token is first created.  This code checks a condition - in this case, that the Live ID email is in the microsoft.com domain - and, adds the user to the Admin role if appropriate.  Make sure to modify the if condition so that it returns the correct value.

Geneva handles everything from there, including storing the claim in the cookie so that it gets passed from page to page.  This allows the developer to simply use the IsInRole() method to determine if a user is in a particular role.  ASP.NET uses this method under the covers to authorize access to pages based on the authorization configured in web.config.

Once Active Directory domains get federated with Live ID (or if you use this code to call a different STS), you will get additional claims from the STS.  In AD's case, you will get some Group membership claims.  It is very simple within the event to map the Group claims to Role claims.  This will allow the web developer to use the familiar IsInRole() method vs. having to check the claims.

Using ACS to manage roles

Another way to accomplish this is to use Access Control Service to provide role membership information.  When you go to the ACS section on the Azure Services Platform portal, you need to click the Advanced button and the localhost Scope URI so that you can configure roles.

Once on the advanced scope management page, click the Claim Types "tab".  You will notice several claim types defined, including UserName, Windows Live ID, Group, etc.

One option is to add users to an Admin group and then use code in the SessionSecurityTokenCreated event to add the user to the role that each group represents.

Another option is to add a Role claim type to ACS.  To do this, click the Add Claim Types button.

On the Add Claim Types page, enter Role into the Display Name input box and enter http://schemas.microsoft.com/ws/2008/06/identity/claims/role into the Claim Type input box, then click Save.

You should now see a Role claim type displayed on the Claim Types page.

Next, click on the Rules tab, then click the Add Rule button.

In the Input Claims section, set the type dropdown to Windows Live ID, enter your Windows Live ID into the Value field, and set the Issuer to live.com.  You can add as many Windows Live IDs as you wish, just make sure to set the input claims type combo box to Any.

In the Output Claims section, select Role from the Type dropdown, enter Admin into the Value field, and click Save.

Now run the sample, click on the Live ID Login button, login with a Live ID that you added to the Admin role, and you should see the Admin role displayed on the home page.  You should also be able to access the pages in the Admin folder.

All without any code!

I didn't mention this in my earlier posts, but this code won't currently run on Azure.  It also won't work on shared hosting at GoDaddy. It works great at GoGrid.

Geneva also enhances the standard ASP.NET authorization capabilities available via web.config.  To use this example, follow the instructions for the previous post and, once it is running, do the following:

Use web.config to prevent anonymous access to the entire site.  To do this, uncomment the authorization block at lines 60 - 62 so that it looks like this:

<authorization>
     <deny users="?"/>
</authorization>

Also in web.config, just before the configuration close tag on the last line, insert the following configuration information:

<location path="default.aspx">
   <system.web>
      <authorization>
          <allow users ="*" />
      </authorization>
   </system.web>
</location>

<location path="images">
   <system.web>
      <authorization>
          <allow users ="*" />
      </authorization>
   </system.web>
</location>

These config params override the main authorization config and allow anonymous access to default.aspx and everything in the images folder.

Lastly, comment all of the code in global.asax.cs.

Press F5 and the default page will display.  When you click on the Page 2 link, you will be redirected to the Live login page.

Unfortunately, there is a bug in the CTP and you will get a 400 error.  Simply add the line below to the end of the url in the address bar and press enter, and you will be correctly redirected to the login page.

&whr=https://login.live.com

In a future post, I will explain a few different ways to integrate role support to the web application via ACS.

ACS is currently available as a CTP.  The CTP provides federation with Live IDs and is the easiest way I've found to integrate Live ID into a web site.  Even though there are some CTP maturity issues, you can still do quite a lot with the CTP and we are very excited about the direction ACS is headed.  While investigating ACS for RXG, I put together a simple example that shows how to integrate ACS into a web app.  The Visual Studio 2008 sample code is available below.  Many thanks to Justin for providing most of the code and answering my questions.

Before you download the code ...

There are a couple of things you need to do in order to get the sample to work.  The first is to register for the .NET Services CTP, install the SDKs, and setup a .NET Services solution.  You will also need to install the Geneva beta.

Next, go to the portal and setup ACS by signing in then clicking on Getting Started then "Access Control Service" on the getting started page.

Once on the ACS page, click the Basic button.

On the Basic View page, click the Next button

On the Wizard page, enter https://localhost into the Application URL field, leave the certificate field blank, and click next.  In a production app, you would want to supply a certificate for security reasons.

On the Access Control Rules page, change the type of the claim to Windows Live ID.  Enter an * in the value field and change the issuer to live.com.  Change the output claim type to e-mail, check the copy input value box, and click save.

You should end up on the Rules page with a single rule that looks like this:

Download the sample code from here, unzip, and open the solution.  Make sure to stop IIS if it’s running as the sample requires port 80 on localhost.

Open web.config and change the [[solution]] value in the Issuer url to the correct solution name (it’s displayed on the ACS portal pages).

 Open global.asax.cs and set a breakpoint in the Application_AuthenticateRequest event.

Press F5 and you will hit the breakpoint.  Press F5 again time and the default page will load.

Click on the Page 2 link and you will be redirected to the live.com login page.  After logging in with a valid Live ID, you should see your authentication information on the default page.  Click on the Page 2 link again and you should be taken to Page2.aspx.

What just happened?

The Application_AuthenticateRequest event redirects to live.com to get the token which is automatically handled by the Geneva provider.  The rediretion code in the AuthenticateRequest event is exactly the same as the code in the btnFederate_Click event.  The code is very simple as it just gets a reference to the WSFederationAuthenticationModule in ApplicationInstance.Modules, creates a SignInRequestMessage, then redirects.

Geneva is configured with the <microsoft.identityModel> section in web.config.  As mentioned above, make sure to modify the issuer value to point to your solution.  Also note that authentication mode is set to None.  Most of the Geneva magic happens because of the web.config values.  I still don't fully understand all of the options, but the basics make sense once you play around with it a little.

Keep it simple

I tried to keep this as simple as possible as I found it difficult to get everything setup correctly the first time.

ACSSample.zip