Shawn Cicoria - CedarLogic

Building scalable web applications with Windows Azure (ed. and on premise too!)

Matthew Kerner’s session at BUILD covers many of the patterns and approaches that a well designed and highly scalable solution can do to make the most efficient use of the platform.

Truth is many of the areas Matthew covers should be for on Premise too – including use of Windows Azure CDN...

  At about ~30:00 in Matthew references one of my posts on Windows Azure CDN and using it with your Compute role (hosted service) as an CDN origin…

Building scalable web apps with Windows Azure
http://channel9.msdn.com/events/BUILD/BUILD2011/SAC-870T

Bringing Hyper-V to “Windows 8” - Building Windows 8 - Site Home - MSDN Blogs

This is huge – and a welcomed addition.  Been waiting too long for this.

Bringing Hyper-V to “Windows 8” - Building Windows 8 - Site Home - MSDN Blogs

Hosted Service as a Windows Azure CDN Origin Tips

The Windows Azure Content Delivery Network (CDN) helps improve the solution experience by putting content closer to the end-user, enhances availability, geo-distribution, scalability, lower latency delivery, and performance. If that’s the goal we want to be sure that when we instantiate the source of this content at the origin it’s as CDN friendly as we need.

In Windows Azure, when you’re running under IIS7.x /ASP.NET you have to be aware of the inherent behavior associated with Output Caching as it is part of the standard deployment of IIS7.x.

Some of that inherent behavior affects how cache-friendly your content (Http Response) will be as the CDN directly consumes your Hosted Service endpoint ( http://yourservice:80|443/cdn ) on behalf of your users.

If you don’t understand how your solution emits these HTTP headers, you will end up with NO caching – defeating the purpose of the CDN (in fact making performance worse) and additional costs incurred.

The areas we’ll briefly take a look at here are:

• Working with the ASP.NET OutputCache module for CDN Friendly HTTP Headers
• Vary:* Headers
• Compressed content with the CDN
• Use of IIS Virtual Application / Directories under Windows Azure
• Provide your own OutputCache module implementation

Working with the ASP.NET OutputCache Module

Default behavior

The following code is an example of what developers generally provided with anticipation that the HTTP headers, specifically the Cache-control header will be emitted with a CDN friendly HTTP header – or any cache for that matter.

using (var image = ImageUtil.RenderImage(…))
 {
     context.Response.Cache.SetMaxAge(TimeSpan.FromMinutes(Constants.MA));
     context.Response.Cache.SetCacheability(HttpCacheability.Public);
     context.Response.ContentType = "image/jpeg";
     image.Save(context.Response.OutputStream, ImageFormat.Jpeg);
     context.Response.OutputStream.Flush();
 }

Under ASP.NET 3.5/4.x, this will result in the following

---request begin---
GET /image/0.jpg HTTP/1.0
User-Agent: Wget/1.11.4
Accept: */*
Host: az30993.vo.msecnd.net
Connection: Keep-Alive
---response begin---
HTTP/1.0 200 OK
Cache-Control: public
Content-Type: image/jpeg
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 08 Jul 2011 11:26:01 GMT
Content-Length: 6976
X-Cache: MISS from cds168.ewr9.msecn.net
Connection: keep-alive

With that set of headers, you will encounter a cache MISS on every request – with a read-through to the Hosted Service origin. You might not notice the impact right away as it can get picked up by the OutputCache module – but you’ve defeated the purpose of the CDN – and made the request performance worse.

The sample solution with this post provides a set of test scenarios for manipulating the HttpResponse under a standard IHttpHandler and under MVC3. If you take a look at the code you’ll see that 3 things are done to help diagnose the situation.

1. Request Logger – this is a simple request logger that captures requests for the purposes of providing a simple view against the incoming requests (could have used IIS logs, but this is a simple way to get the requests I’m interested in and display them)
2. Kernel caching is disabled via the web.config – with this enabled requests won’t make it into your ASP.NET pipeline when it’s a cache hit – giving you a false positive on understanding if and when CDN requests are “leaking” through and not being cached at the CDN
3. OOB OutputCache module is removed, then re-added – this ensures it’s lower in the module list at request time allowing the Request Logger to be higher up in the call chain so I’m sure to capture the inbound requests – if they’re cached or not in the OutputCache module

Set SlidingExpiration on Response

The easiest fix is to ensure you set SlidingExpiration to true on the response. This will ensure that the Cache-control header will contain your desired “public, max-age=xxxx”

public void ProcessRequest(HttpContext context)
{
    using (var image = ImageUtil.RenderImage(…)
    {
       context.Response.Cache.SetCacheability(HttpCacheability.Public);
       context.Response.Cache.SetMaxAge(TimeSpan.FromMinutes(Config.MaxAge));
       context.Response.ContentType = "image/jpeg";
       context.Response.Cache.SetSlidingExpiration(true);
       image.Save(context.Response.OutputStream, ImageFormat.Jpeg);
    }
}

Set an explicit Expires on the Response

public void ProcessRequest(HttpContext context)
{
    using (var image = ImageUtil.RenderImage(…)
    {
      context.Response.Cache.SetCacheability(HttpCacheability.Public);
      context.Response.Cache.SetExpires(DateTime.Now.AddMinutes(Config.MA));
      context.Response.ContentType = "image/jpeg";
      image.Save(context.Response.OutputStream, ImageFormat.Jpeg);
      context.Response.OutputStream.Flush();
    }
}

Use Downstream as the location when using the MVC OutputCache Attribute

[OutputCache(CacheProfile = "CacheDownstream")]
public ActionResult Image3()
{
    MemoryStream oStream = new MemoryStream();
    using (Bitmap obmp = ImageUtil.RenderImage(…)
    {
       obmp.Save(oStream, ImageFormat.Jpeg);
       oStream.Position = 0;
       return new FileStreamResult(oStream, "image/jpeg");
    }
}

//web.config
 <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="CacheDownstream" 
               location="Downstream" 
               duration="1000" 
               enabled="true"/>
        </outputCacheProfiles>
      </outputCacheSettings>

Append a query string

Providing a query string on the request affects the Cache-control header. Even if you add just a “?” after the URL path, the OutputCache module will then emit your intended max-age.

Disable OutputCache module – via config

You can do this by removing it from the ASP.NET pipeline altogether, or remove it in the sub-path where /cnd is located (or Virtual Application – see section later). This disables all Output caching for all requests.

Disable OutputCache module – via code – per request

You can also choose to bypass the OutputCache by affecting the Response with the following code

public void ProcessRequest(HttpContext context)
{
    using (var image = ImageUtil.RenderImage(…)
    {
       context.Response.Cache.SetCacheability(HttpCacheability.Public);
       context.Response.Cache.SetMaxAge(TimeSpan.FromMinutes(Config.MA));
       context.Response.Cache.SetNoServerCaching();
       context.Response.ContentType = "image/jpeg";
       image.Save(context.Response.OutputStream, ImageFormat.Jpeg);
       context.Response.OutputStream.Flush();
    }
}

Implement your own OutputCache module

You can take a look at the links in the section on implementing your own OutputCache module to get an idea on the implementation effort, but the reasoning why you would want to is varied – which I’ll cover a couple of reasons in that section.

Vary:* Headers and Caching

Ensure you’re not emitting Vary:* by headers at all if you want to take advantage of caching – either with the Windows Azure CDN or not – as the specification indicates responses with Vary:* should not be cached and only handled at the origin.

From RFC2616: "A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server."

Compressed content with the CDN

One of the reasons you would want to move your origin from Windows Azure Storage to a Hosted Service is to take advantage of compression. As part of IIS7.x, you can ensure that static and dynamic compression is enabled for your content – this will then cascade through to the Windows Azure CDN and provide an overall better experience for your end users.

Use of IIS Virtual Application / Directories under Windows Azure

Today, using Hosted Service as an origin to Windows Azure CDN requires a production deployment of your service listening at the path http://yourserviceDnsName:80|443/cdn. Currently we do not support Hosted Services as origins in staging.

All that is required is that your service provide responses under the /cdn path. You can achieve this with a WebRole that has a directory (path) under your main site.

What happens if you need (or desire) to isolate that path (/cdn)? Under Windows Azure, you can take advantage of IIS Virtual Applications / Directories under your main WebRole.

The following Service Definition illustrates the approach by taking advantage of the Full IIS model and the VirtualApplication element. The key to the approach here for your solution in the development fabric is to ensure the physical directory is relative to the MainWeb path.

<ServiceDefinition name="TR13VirtualApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="MainWeb" vmsize="ExtraSmall">
    <Sites>
      <Site name="Web">
        <VirtualApplication name="cdn" physicalDirectory="../MainWebCdn" />
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    … 

This results in a deployment up on Windows Azure as the following – with a single site, and 2 application pools:

Simple VS2010 Solution is also provided at the end of the post and the following links provide further detail:

Creating Virtual Applications / Directories

The Windows Azure Training kit contains a sample walkthrough that demonstrates the approach.

http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_advancedwebandworkerrolesvs2010lab_topic2.aspx

Additionally, Wade Wegner goes into a bit of detail as well.

http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/

Why provide your own OutputCache module implementation?

If that content is VERY expensive to produce….

You now have N (# of instances) producing possibly exact or similar replicas of your content. Not exactly a desirable effect if your transaction costs are high (maybe you’re reaching out to external services, or on premise mainframes, etc.)

Take advantage of Windows Azure AppFabric Caching

Either replacing the OutputCache module with your own implementation, or leveraging your own request model (that will still work with or bypass the OutputCache module) you can instantiate a single copy of that content in AppFabric Caching – thereby reducing the overall cost associated with repetitive content creation. Whatever your choice, ensure to factor in operational costs of AppFabric to see if it meets your economic model.

Implement your own OutputCache

The following links provide some guidance on replacing OutputCache module – which can be done at the /cdn path level if required.

Custom OutputCacheProvider

The following is a sample implementation of a custom OutputCache module under NetFx 4.0.

http://weblogs.asp.net/gunnarpeipman/archive/2009/11/19/asp-net-4-0-writing-custom-output-cache-providers.aspx

ASP.NET 4.0 Caching Overview

Check out the following link on ASP.NET 4.0 caching in general to get an idea of OutputCache module.

http://msdn.microsoft.com/en-us/library/ms178597.aspx

Solution Files

CDN Test Solution

Virtual App Sample

Raffaele Rialdi DeployManager June 2011 edition–Now supports SAN certificates

Raffaele Rialdi has been adding features to his certificate management tool.  Already supporting wildcard certificates, he’s now added SAN cert support.

But it’s more than certificate management too.

IAmRaf - Tools

Identity Claims Encoding for SharePoint

Just to remind myself, the list of claim types and their encodings are listed here at the bottom.

http://msdn.microsoft.com/en-us/library/gg481769.aspx

Where for example:

i:0#.w|contoso\scicoria

‘i’ = identity, could be ‘c’ for others

# == SPClaimTypes.UserLogonName

. == Microsoft.IdentityModel.Claims.ClaimValueTypes.String

Table for reference:

Table 1. Claim types encoding

Table 2. Claim value types encoding

Creating Wildcard Certificates with makecert.exe

Be nice to be able to make wildcard certificates for use in development with makecert – turns out, it’s real easy.  Just ensure that your CN=  is the wildcard string to use.

The following sequence generates a CA cert, then the public/private key pair for a wildcard certificate

REM make the CA
rem CA Certificate:
makecert -r -pe -n "CN=AA Contoso Test Root Authority" -ss CA -sr CurrentUser -a sha1 -sky signature -cy authority -sv CA.pvk CA.cer -len 2048


REM now make the server wildcard cert
makecert -pe -n "CN=*.contosotest.com" -a sha1 -len 2048 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -ic CA.cer -iv CA.pvk -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv wildcard.pvk wildcard.cer

pvk2pfx -pvk wildcard.pvk -spc wildcard.cer -pfx wildcard.pfx

Lorem Ipsum–Generating in Word 2010

Well, apparently I missed this hidden feature having used the Lorem Ipsum website for some time, but if you enter the following in blank Word document – you’ll get 10 paragraphs of generated text:

=Lorem(10)

Such as:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa. Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero, sit amet commodo magna eros quis urna.

Nunc viverra imperdiet enim. Fusce est. Vivamus a tellus.

Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Proin pharetra nonummy pede. Mauris et orci.

Aenean nec lorem. In porttitor. Donec laoreet nonummy augue.

Suspendisse dui purus, scelerisque at, vulputate vitae, pretium mattis, nunc. Mauris eget neque at sem venenatis eleifend. Ut nonummy.

Fusce aliquet pede non pede. Suspendisse dapibus lorem pellentesque magna. Integer nulla.

Donec blandit feugiat ligula. Donec hendrerit, felis et imperdiet euismod, purus ipsum pretium metus, in lacinia nulla nisl eget sapien. Donec ut est in lectus consequat consequat.

Etiam eget dui. Aliquam erat volutpat. Sed at lorem in nunc porta tristique.

Proin nec augue. Quisque aliquam tempor magna. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

Nunc ac magna. Maecenas odio dolor, vulputate vel, auctor ac, accumsan id, felis. Pellentesque cursus sagittis felis.

HACK: Forcing FBA Token Refresh against SPClaimProvider with No Credential Challenge

The approach takes advantage of the SP 2010 OOB Session Token handler and FBA claims provider implementation that during a period of token lifetime, if there is activity during the period of time that can be defined as "EW" in the image in the section "Background" below, that the SPSecurityTokenManager will, with the FBA provider, reissue a Session Token with new SessionToken ValidTo and ValidFrom times without forcing a re-challenge for user credentials (username and password).

Additionally, it takes advantage of the ability to provide an event handler, on the SessionAuthentcationModule (SPSessionAuthenticationModule) to cause a reissue of the token temporarily with an expiry time (ValidTo) that will cause a SPSessionToken cache miss – thus forcing the re-issue by the SPSecurityTokenManager.

General Approach

The following is a contrived example and uses a rudimentary approach for determine how/when to indicate that the token should be "refreshed" This is done by hooking into the WIF Session Authentication Module's (SAM) Event "SessionSecurityTokenReceived".

The approach taken, and shown on the internet in several posts is to subclass the HttpApplication implementation.

The approach I recommend is to leverage the ability of any HttpApplication by ways of built in ability to identify all HttpModules loaded for that ASP.NET application (SP included) and determine if there are Event handlers specified by ways of the Global.asax in the Root of the SP IIS Site. This is handled by the System.Web.HttpApplication.HookupEventHandlersForApplicationAndModules method.

Note: There are alternatives that I've also tested that work – 1 approach is to register a new HttpModule, then in that HttpModule is to register "1" time a handler for the SAM's SessionSecurityTokenReceived event. This requires a method of indicating at the application level that a handler has already been registered.

Scenario Supported

The general scenario is:

1. User is already logged onto the site with a valid token
2. At time required to force a Claims refresh, user will click a link or system will determine how to initiate an HttpRequest that will call the logic required for forcing the refresh
3. System receives request
4. SessionAuthenticationModule raises event that custom code will handle
   1. This is done by HttpRequest inspection – the sample looks for a Url that contains "RefreshToken.aspx" – there are other means to provide a similar approach.
5. Custom code identifies the SP LogonTokenCacheExpirationWindow
6. Using LogonTokenCacheExpirationWindow, custom code forces a re-issue of token that has a ValidTo that will fall into the LogonTokenCacheExpirationWindows – eg.

DateTime newValidTo = DateTime.UtcNow.Add(logonWindow); 

1. System (SP Session Cache) determines that the token requires a re-issue
2. System calls SPSecurityToken Manager – to reissue all claims for user, bypassing the Logon credentials prompt
3. During the SPSecurityToken manager re-issue any custom SPClaimProvider types loaded are also called – using FBA and SPClaimProvider will make a call to its FillClaimsForEntity inside of the SP STS.
4. Session continues with new SessionToken using configuration based values for ValidFrom, ValidTo as defined in the SPSecurityTokenConfig.

Sample Code for Event Handler

The sample code uses another class to contain the code; your implementation could just as easily keep this in the global.asax – however, I'm of the belief that the global.asax should be kept as pristine as possible.

The following code is placed in an assembly that is resolvable through normal fusion – that is, it could be a private assembly. I've chosen GAC in the sample project just for the ease of development.

The code below handles the event and just looks for a page (Url) that contains a well-known request string. This could be anything, but ensure that it's not a common page and based upon the application needs, how your logic will determine a need to refresh all claims.

<%@ Assembly Name="Microsoft.SharePoint" %>
<%@ Assembly Name="RefreshClaimsSample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=329ca2a6e4eeb8c6" %>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
<%@ Import Namespace="Microsoft.IdentityModel.Web" %>
<%@ Import Namespace="Microsoft.IdentityModel.Tokens" %>
<%@ Import Namespace="Microsoft.SharePoint.IdentityModel" %>

<script runat="server">
    void SessionAuthentication_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e) 
    {
        RefreshClaimsSample.SampleRefreshClaims.ForceRefreshClaims(sender, e);
    }
</script>

public static void ForceRefreshClaims(object sender, SessionSecurityTokenReceivedEventArgs e)
{
    if (HttpContext.Current.Request.Url.AbsoluteUri.Contains("RefreshClaims.aspx"))
    {
        SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
        var logonWindow = SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow;

        DateTime newValidTo = DateTime.UtcNow.Add(logonWindow);

        e.SessionToken = sam.CreateSessionSecurityToken(
            e.SessionToken.ClaimsPrincipal,
            e.SessionToken.Context,
            e.SessionToken.ValidFrom,
            newValidTo,
            e.SessionToken.IsPersistent);

        e.ReissueCookie = true;
    }
}

Wiring up Event Handler

In the SP Global.asax provided a method signature that matches the event from the SAM.

The requirements are that the signature is as follows:

void <moduleNameFromConfig>_<eventName> ( eventArgsType )

Where:

1. moduleNameFromConfig – must match the name attribute from the module as specified in the /system.webServer/modules/add/@name element.
2. eventName – must match the event name as defined in the HttpModule's public event
3. eventArgsType – must match the event arguments type that is defined for the event.

Background

In the above diagram, the settings:

• TL = FormsTokenLifeTime
• EW = LogonTokenCacheExpirationWindow

These settings are obtained and modified via PowerShell under the SPSecurityT0kenServiceConfig set of cmdlets.

For the following samples, assume the following:

• TL = 10 Minutes
• EW = 4 Minutes

TL – EW = 6 Minutes

Solution Zip

SharePoint 2010 FBA and Sliding Sessions

This is to provide a little bit of explanation on the implementation of FBA authentication with SP 2010. There have been blog posts that indicate there are no sliding sessions, but with a little manipulation and understanding of some of the settings, there is somewhat of support for sliding sessions and re-issuance of tokens. The current model provides for a little trade-off on performance as re-requests to the FBA providers and also any SP Custom Claim providers can have impact on overall performance.

The following diagram represents the initial static view of the SP 2010 Security Token Service Configuration settings that control the management of Tokens issued under Forms Based Authentication (FBA) authentication.

The current SP 2010 April 2011 CU’s does support a level of sliding sessions as long as a request (user activity) occurs in the window of time after token issuance (logon or re-issuance) defined in the “EW” segment below.

In the above diagram, the settings:

• TL = FormsTokenLifeTime
• EW = LogonTokenCacheExpirationWindow

These settings are obtained and modified via PowerShell under the SPSecurityT0kenServiceConfig set of cmdlets.

For the following samples, assume the following:

• TL = 10 Minutes
• EW = 4 Minutes
• TL – EW = 6 Minutes

Example 1:

1. User Logon occurs
2. User is Inactive for 11 minutes (> 10 minutes)
3. At next request: System Presents Forms based logon (or identity selector) to user forcing re-authentication (All Claims Providers Called)

Example 2:

1. User Logon occurs
2. User is Inactive for 3 minutes
3. User issues Request
4. Token is NOT updated as request occurred in the “TL – EW” window
5. User remains Inactive for 8 more minutes (> 7 or more than 3 + 7 = 10, which is the original window
6. At next request: System Presents Forms based logon (or identity selector) to user forcing re-authentication (All Claims Providers Called)

Example 3:

1. User Logon occurs
2. User is inactive for 8 minutes
3. User issues Request
4. System attempts to re-issue token, skipping password check
5. System re-issues new Token with updated ValidFrom / ValidTo timestamp based upon current clock (All Claims Providers Called)
6. Entire “window” is now shifted based upon existing configured values

Note in the above scenarios that the “(All Claims Providers Called)” indicates that the Claims Providers registered for the Web Application / Site are then called; any custom SPClaimProvider implementations will have the method FillClaimsForEntity called at that time

Adding and Removing SPClaimProvider via PowerShell

There are really 2 ways to get a SPClaimProvider registered – 1 via a Farm Feature activation.  The other is via PowerShell. 

However, the documentation on how to remove is not that clear.

The following code will remove it based upon a TypeName.  Other identifiers can be used.

In order to remove:

Get-SPClaimProvider | ForEach-Object { 
    Write-Host $_.TypeName
    IF ( $_.TypeName -eq "SimpleClaimsProvider.LVClaimsProvider")
        {
            Write-Host "Found"
            $cp = $_
        }
    
    }
    
    
$cp.DisplayName

Remove-SPClaimProvider $cp

I want my $8.5 B back…

Skype reporting “some users” can’t login.  Odd, when you’re “some users” you can’t imagine the entire world is not feeling your pain.

And numerous crashes.

Know what Process is calling your SPClaimProvider

If you’re writing a custom SharePoint Claims Provider (SPClaimProvider) in order to augment claims, it’s important to also understand what process is executing your specific code path.  In the situation where you are making calls to a DB or service endpoint you will need to understand which process actually makes that call.

In situations when running in a Trusted Subsystem model, you’ll also need to RunWithElevated in order to have that code path execute in the context of the Windows Principal for that process.

The following table illustrates for the abstract members of the SPClaimProvider class when implemented and where they execute:

So, if you have your persistence in a SQL DB, and your using Windows Authentication (and using RunWithElevated) you’ll need to grant (or have) to the appropriate SQL permissions; generally, I’ve just granted “datareader”.

Forcing use of the same Master Page in sub-sites without Publishing

This seems to come up a few times.  The following sample script in PS applies a common master page across all SPWebs in a site collection.

$site = Get-SPSite http://fba.contosotest.com/dv1
$site | Get-SPWeb -limit all | ForEach-Object { $_.MasterUrl = "/dv1/_catalogs/masterpage/custom_v4.master";$_.Update() }
$site.Dispose()

Thanks to Phil Childs - http://get-spscripts.com/2010/09/changing-master-page-on-sharepoint.html

How does the Windows Azure Fabric controller do that?

Kevin Williamson has a great post on the overall flow of things from the point of publishing of your package up on the Windows Azure Developer Portal to Run().

These are good things to know as many times you need to inject steps, tasks, context at various stages of your service instance’s lifetime.

http://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx

Windows Azure Role Architecture - Windows Azure - Troubleshooting & Debugging - Site Home - MSDN Blogs

CloudNinja - Windows Azure Multi-tenant Sample - Home

So, as one of the OneTAP leads for Windows Azure focusing on the BizSpark folks, I run into many questions regarding HOWTO and in areas of Auto-Scaling, provisioning, authentication.

The folks at Full Scale 180 (http://www.fullscale180.com) have created a nice sample application that demonstrates the following:

Key Features

• Metering
• Automated Scaling
• Federated Identity
• Provisioning

• Sample source code
• Design document
• Setup guide
• Sample walkthrough

CloudNinja - Windows Azure Multi-tenant Sample - Home