@woloski: when would you use a delegatingchannel vs httpoperationhandler? I’ve found different samples using both

And indeed he replied. I like things explained in plain English from someone who really knows the thing, so here are the tweets with some color coding to separate one from the other.

NOTE: make sure to also read Glenn’s post which goes into much more detail.

@gblock: there are significant diffs. One is for pure http request / resp related concerns (message handlers) the other for app level

@gblock: one is global / knows nothing about the service the other does knows about the service.

@gblock: one is a Russian doll allowing pre-post handling, the other is a sequential pipeline.

@gblock: one handles model binding type scenarios (operation handlers) the other does not

@gblock: one is async (message handlers) the other is sync. So if you have something io bound use message handlers

@gblock: for cross cutting http concerns like etags, or if-none-match use message handlers.

@gblock: for validation / logging of app data use operation handlers. For security you might use both as Howard did for Oauth

@gblock: if it is truly cross cutting and doesn’t require details about the operation itself like parameter values.

@gblock: message handlers can handle requests dynamically ie they can handle a request to \foo without an op foo

@gblock: architecturally I think they make sense even though there is some overlap. HTTP concerns vs app concerns is the line.

For our case we will use HttpOperationHandlers because we want access to the operation to check that it contains an attribute.

Case closed!

Dejo aqui el link del webcast que fue grabado para aquellos que les interese.

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032494854&culture=es-AR

Problem

WebDeploy throws an out of disk exception when creating a package

There is not enough space on the disk. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count) at System.IO.BinaryWriter.Write(Byte[] buffer, Int32 index, Int32 count) at Microsoft.Web.Deployment.ZipEntry.ReadFromFile(String path, Boolean shouldCompress, BinaryWriter tempWriter, Stream stream, FileAttributes attr, DateTime lastModifiedTime, String descriptor, Int64 size) at Microsoft.Web.Deployment.ZipEntry..ctor(String path, DeploymentObject source, ZipFile zipFile)

Analysis

WebDeploy uses a temp path to create temporary files during the package creation. This folder seems to have a 100MB quota according to MSDN, so if the package is more than that, the process will throw an IO exception because the “disk is full” even though there is plenty of space. Below a trace of Process Monitor running from the Azure Web Role showing the CreateFile returning DISK FULL.

By looking with Reflector, we can validate that WebDeploy is using Path.GetTempPath.

Solution

Since we can’t change WebDeploy code nor parameterize it to use a different path, the solution is to change the TEMP/TMP environment variables, as suggested here http://msdn.microsoft.com/en-us/library/gg465400.aspx#Y976. An excerpt…

Ensure That the TEMP/TMP Target Directory Has Sufficient Space

The standard Windows environment variables TEMP and TMP are available to code running in your application. Both TEMP and TMP point to a single directory that has a maximum size of 100 MB. Any data stored in this directory is not persisted across the lifecycle of the hosted service; if the role instances in a hosted service are recycled, the directory is cleaned.

If the temporary directory for the hosted service runs out of space, or if you need data to persist in the temporary directory across the lifecycle of the hosted service, you can implement one of the following alternatives:

The following code example shows how to modify the target directories for TEMP and TMP from within the OnStart method:

using System;
using Microsoft.WindowsAzure.ServiceRuntime;

namespace WorkerRole1
{
   public class WorkerRole : RoleEntryPoint
   {
      public override bool OnStart()
      {
         string customTempLocalResourcePath =
            RoleEnvironment.GetLocalResource("tempdir").RootPath;
         Environment.SetEnvironmentVariable("TMP", customTempLocalResourcePath);
         Environment.SetEnvironmentVariable("TEMP", customTempLocalResourcePath);

         // The rest of your startup code goes here…

         return base.OnStart();
      }
   }
}

The thing is that we usually have to deal with last minute deployments to Azure that can take more than a minute <grin>. The good news is that some of that pain started to be eased lately.

• First, the Azure team enabled Web Deploy. For development this helped a lot.
• Then, we helped DPE to build the Windows Azure Accelerators for Web Roles, announced by Nate last week. I explained how the accelerator work in a previous post. We actually used the Web Role Accelerator to deploy www.tankster.net (the social game announced on Wednesday). We have the game backend running in two small instances and we had everything ready for the announcement last week but of course there were tweaks on the game till the last minute. We did like 10 deployments in the last day before the release. 10 * 15 minutes per deploy is almost three hours. Instead using the accelerator each deploy took us 30 seconds. The dev team happy with getting 3 hours of our life back.
• Now, to complete the whole picture I saw it might be a good idea to have the same thing but for Worker Roles

So I teamed with Alejandro Iglesias and Fernando Tubio from the Southworks crew and together we created the Windows Azure Accelerator for Worker Roles.

How it works?

You basically deploy the accelerator with your Windows Azure solution and the “shell” worker will be polling a blob storage container to find and load the “real worker roles”. We made it easy so you don’t have to change any line of code of your actual worker role. Simply throw the entry point assembly and its dependencies in the storage container, set the name of the entry point assembly in a file (__entrypoint.txt) and the accelerator will pick it up, unload the previous AppDomain (if any) and create a new AppDomain with the latest version.

How to use it?

You can find the project in github, there is a README in the home page that explain the steps to use it.  Download it and let us know what you think!

I would like to have a Visual Studio template to make it easier to integrate with existing solutions.

Enjoy!

Also, as the title says, and as Maarten says in his blog, if you have lots of small websites you don’t want to pay for 100 different web roles because that will be lots of money. Since Azure 1.4 you can use the Full IIS support but the experience is not optimal from the management perspective because it requires to redeploy each time you add a new website to the cscfg.

In short, the best way I can describe this accelerator is:

It transform your Windows Azure web roles into a dedicated elastic hosting solution with farm support and a very nice IIS web interface to manage the websites.

I won’t go into much more details on the WHAT, since Nathan and Maarten already did a great job in their blogs. Instead I will focus on the HOW. We all love that things work, but when they don’t work you want to know where to touch. So, below you can find the blueprints of the engine.

Below some key code snippets that shows how things work.

The snippet below is the WebRole Entry Point Run method. We are spinning the Synchronization Service here that will block the execution. Since this is a web role, it will launch the IIS process as well and execute the code as usual. 

public override void Run()
{
    Trace.TraceInformation("WebRole.Run");

    // Initialize SyncService
    var localSitesPath = GetLocalResourcePathAndSetAccess("Sites");
    var localTempPath = GetLocalResourcePathAndSetAccess("TempSites");
    var directoriesToExclude = RoleEnvironment.GetConfigurationSettingValue("DirectoriesToExclude").Split(';');
    var syncInterval = int.Parse(RoleEnvironment.GetConfigurationSettingValue("SyncIntervalInSeconds"), CultureInfo.InvariantCulture);

    this.syncService = new SyncService(localSitesPath, localTempPath, directoriesToExclude, "DataConnectionstring");
    this.syncService.SyncForever(TimeSpan.FromSeconds(syncInterval));
}

Then the other important piece is the SyncForever method. What this method does is the following:

• Update the IIS configuration using the IIS ServerManager API by reading from table storage
• Synchronize the WebDeploy package from blob to local storage (point 4 in the diagram)
• Deploy the sites using WebDeploy API, by taking the package from local storage
• Creates and copies the WebDeploy package from IIS (if something changed)

public void SyncForever(TimeSpan interval)
{
    while (true)
    {
        Trace.TraceInformation("SyncService.Checking for synchronization");

        try
        {
            this.UpdateIISSitesFromTableStorage();
        }
        catch (Exception e)
        {
            Trace.TraceError("SyncService.UpdateIISSitesFromTableStorage{0}{1}", Environment.NewLine, e.TraceInformation());
        }

        try
        {
            this.SyncBlobToLocal();
        }
        catch (Exception e)
        {
            Trace.TraceError("SyncService.SyncBlobToLocal{0}{1}", Environment.NewLine, e.TraceInformation());
        }

        try
        {
            this.DeploySitesFromLocal();
        }
        catch (Exception e)
        {
            Trace.TraceError("SyncService.DeploySitesFromLocal{0}{1}", Environment.NewLine, e.TraceInformation());
        }

        try
        {
            this.PackageSitesToLocal();
        }
        catch (Exception e)
        {
            Trace.TraceError("SyncService.PackageSitesToLocal{0}{1}", Environment.NewLine, e.TraceInformation());
        }

        Trace.TraceInformation("SyncService.Synchronization completed");

        Thread.Sleep(interval);
    }
}

My advice: If you are using Windows Azure today don’t waste more time doing lengthy deployments  Download the Windows Azure Accelerators for Web Roles.

Enjoy!

En este ejemplo muestro lo siguiente:

• Creo un sitio web de cero y agrego un identity provider de prueba (Add STS Reference)
• Me falla una cosa con certificados y hago un poco de troubleshooting
• Configuro el mismo sitio en Windows Azure Access Control (ACS) y genero la relacion de confianza entre mi sitio y ACS
• Configuro otros identity providers en ACS
• Muestro como podemos logearnos a una aplicacion utilizando diferentes proveedores de identidad. En particular muestro el ADFS de Microsoft,  el ADFS de Southworks, Google, LiveID, etc.

Sobre el final contesto algunas preguntas…

Espero que les sea util!

We wanted a non-intrusive solution. This means being able to use the usual jQuery client (not learning a new client js API) and try to keep to the minimum the amount of changes in the client and server code. JSONP is an option but it does not work for POST requests. CORS is another option that I would like to try but I haven’t found a good jQuery plugin for that.

So in the end this is what we decided to use:

• WCF Web API to implement the REST backend (works also with MVC)
• jQuery to query the REST backend
• jQuery plugin (flXHR from flensed) that overrides the jQuery AJAX transport with a headless flash component
• Windows Azure w/ WebDeploy enabled to host the API

Having a working solution requires the following steps:

1. Download jQuery flXHR plugin and add it to your scripts folder
2. Download the latest flXHR library
3. Put the cross domain policy xml file in the root of your server (change the allowed domains if you want)

   <?xml version="1.0"?>
   <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
   <cross-domain-policy>
   
     <allow-access-from domain="*" />
     <allow-http-request-headers-from domain="*" headers="*" />
   
   </cross-domain-policy>
   

Here is some JavaScript code that register the flXHR as a jQuery ajax transport and make an AJAX call when a button is click

<script type="text/javascript">
    var baseUrl = "http://api.cloudapp.net/";

    $(function () {
        jQuery.flXHRproxy.registerOptions(baseUrl, { xmlResponseText: false, loadPolicyURL: baseUrl + "crossdomain.xml" });
    });

    $.ajaxSetup({ error: handleError });

    $("#btn").click(function () {
        $.ajax({
            url: baseUrl + "resources/1",
            success: function (data) {
                alert(data);
            }
        });
    });

    function handleError(jqXHR, errtype, errObj) {
        var XHRobj = jqXHR.__flXHR__;
        alert("Error: " + errObj.number
        + "\nType: " + errObj.name
        + "\nDescription: " + errObj.description
        + "\nSource Object Id: " + XHRobj.instanceId
    );
    }
</script>

It’s important to set the ajaxSetup, otherwise POST requests will be converted to GET requests (seems like a bug in the library)

Finally, make sure to include the following scripts

<script src="/Scripts/jquery-1.6.2.js" type="text/javascript"></script>
<script type="text/javascript" src="/Scripts/flensed/flXHR.js"></script>
<script src="/Scripts/jquery.flXHRproxy.js" type="text/javascript"></script>

The nice thing of this solution is that you can set the baseUrl to an empty string and remove the “registerOptions” and everything will keep working just fine from the same domain using the usual jQuery client.

This is the client with (default.html)

This is the server implemented with WCF Web API running in Azure

Turning on the network monitoring on IE9, we can see what is going on behind the scenes.

Notice the last two calls initiated by Flash. The first one downloading the crossdomain policy file and then the actual call to the API.

Some gotchas:

• I wasn’t able to send http headers (via beforeSend). This means that you can’t set the Accept header, it will always be */*
• There is no support for other verbs than GET/POST (this is a Flash limitation)

I uploaded the small proof of concept here.

Enjoy!

Gracias a Guada y Microsoft que grabaron el evento y postearon el material. Me tome el trabajo de subirlo a vimeo para que no se tengan que bajar un wmv completo de 700MB. 

Introduccion a Windows Azure AppFabric Caching

Contenido:

0:00 – 0:03 minutos: intro, agenda y un poco de blah blah

0:03 – 0:25 minutos: Teoria de Windows Azure AppFabric Caching

Introduccion a Windows Azure Access Control Service 2.0 (Teoria)

0:25 – 1:00 minutos: Introduccion a Identidad Federada, Protocolos, Claims, STS, FAQ, ADFSv2 y Windows Azure AppFabric Access Control Service v2.

En un proximo post, la semana que viene, publicare la segunda parte de la charla en donde utilizo el Access Control Service para asegurar una aplicacion y utilzar diferentes proveedores de identidad.

UPDATE: la segunda parte esta publicada

Espero que les sea util!

I’ve used Fiddler and HttpHook in the past to see what’s going on in the wire. These are great tools but they are developer-oriented. If the user who is having issues to login to an app is not a developer, then things get more difficult.

• Either you have some kind of server side log with all the tokens that have been issued and a nice way to query those by user
• Or you have some kind of tool that the user can run and intercept the token

Fred, one of the guys working on my team, had the idea couple of months ago to implement the latter. So we coded together the first version (very rough) of the token debugger. The code is really simple, we are embedding a WebBrowser control in a Winforms app and inspecting the content on the Navigating event. If we detect a token being posted we show that.

Let’s see how it works. First you enter the url of your app, in this case we are using wolof (the tool we use for the backlog) that is a Ruby app speaking WS-Fed protocol. .

After clicking the Southworks logo and entering my Active Directory account credentials, ADFS returns the token and it is POSTed to the app. In that moment, we intercept it and show it.

You can do two things with the token: send it via email (to someone that can read it ) or continue with the usual flow. If there is another STS in the way it will also show a second token.

Since I wanted to have this app handy I enabled ClickOnce deployment and deployed it to AppHarbor (which works really well btw)

If you want to use it browse to and launch the ClickOnce app @ http://miller.apphb.com/

If you want to download the source code or contribute @ https://github.com/federicoboerr/token-requestor

Windows Azure AppFabric Access Control 2.0 has been released last week after one year in the Labs environment and it was officially announced today at MIX. If you haven’t heard about it yet, here is the elevator pitch of ACS v2:

Windows Azure AppFabric Access Control Service (ACS) is a cloud-based service that provides an easy way of authenticating and authorizing users to gain access to your web applications and services while allowing the features of authentication and authorization to be factored out of your code. Instead of implementing an authentication system with user accounts that are specific to your application, you can let ACS orchestrate the authentication and much of the authorization of your users. ACS integrates with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID, Google, Yahoo!, and Facebook

According to the blog published today by the AppFabric team you can use this service for free (at least throughout Jan 2012). Also the Labs environment are still available for testing purposes (not sure when they will turn this off).

We encourage you to try the new version of the service and will be offering the service at no charge during a promotion period ending January 1, 2012.

Now that we can use this for real, in this post I will show you how to create a little widget that will allow users of your website to login using social identity providers like Google, Facebook, LiveId or Yahoo. In this post I will go through the process of creating such experience for your website.

I will use an MVC Web Application, but this can be implemented in WebForms also or even WebMatrix if you understand the implementation details

Step 1. Configure Windows Azure AppFabric Access Control Service

1. Create a new Service Namespace in portal.appfabriclabs.com or if you have an Azure subscription use the production version at windows.azure.com

   
   

2. The service namespace will be activated in a few minutes. Select it and click on Access Control Service to open the management console for that service namespace.
3. In the management console go to Identity Providers and add Google, Yahoo and Facebook (LiveID is added by default). It’s very straightforward to do it. This is the information you have to provide for each of them. I just googled for the logos and some of them are not the best quality, so feel free to change them
   • Google
     • Login Text: Google
     • Image Url: http://www.google.com/images/logos/ps_logo2.png
   • Yahoo
     • Login Text: Yahoo
     • Image Url: http://a1.twimg.com/profile_images/1178764754/yahoo_logo_twit_normal.jpg
   • Facebok / Display Name: Facebook
     • Application Id: …… (follow this tutorial to get one)
     • Application secret: idem
     • Application permissions: email (you can request more things from here http://developers.facebook.com/docs/authentication/permissions/)
     • Image Url: https://secure-media-sf2p.facebook.com/ads3/creative/pressroom/jpg/n_1234209334_facebook_logo.jpg

        

4. The next thing is to register the web application you just created in ACS. To do this, go to Relying party applications and click Add.
5. Enter the following information
   Name: a display name for ACS
   Realm: https://localhost/<TheNameOfTheWebApp>/
   This is the logical identifier for the app. For this, we can use any valid URI (notice the I instead of L). Using the base url of your app is a good idea in case you want to have one configuration for each environment.
   Return Url: https://localhost/<TheNameOfTheWebApp>/
   This is the url where the token will be posted to. Since there will be an http module listen for any HTTP POST request coming in with a token, you can use any valid url of the app. The root is a good choice and, don’t worry, then you can redirect the user back to the original url she was browsing (in case of bookmarking).

   
   

6. Leave the other fields with the default values and click Save. You will notice that Facebook, Google, LiveID and Yahoo are checked. This means that you want to enable those identity providers for this application. If you uncheck one of those, the widget won’t show it.
   
   
7. Finally, go to the Rule Groups and click on the rule group for your web application.
   
   
8. Since each identity provider will give us different information (claims about the user), we have to generate a set of rules to passthrough that information to our application. Otherwise by default that won’t happen. To do this, click on Generate, make sure all the identity providers are checked and save. You should see a screen like this

   
    

Step 2. Configure your application with Windows Azure AppFabric Access Control Service

1. Now that we have configured ACS, we have to go to our application and configure it to use ACS.
   
2. Create a new ASP.NET MVC Application. Use the Internet Application template to get the master page, controllers, etc.
   NOTE: I am using MVC3 with Razor but you can use any version.
   
3. Before moving forward, make sure you have Windows Identity Foudnation SDK installed in your machine. Once you have it, then right click the web application and click Add STS Reference…. In the first step you will have already the right values so click Next
   
   
   
4. In the next step, select Use an existing STS. Enter the url of your service namespace Federation Metadata. This URL has a pattern like this:
   https://<YourServiceNamespace>.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml

    
   

5. In the following steps go ahead and click Next until the wizard finishes.
   
6. The wizard will add a couple of http modules and a section on the web.config that will have the thumbprint of the certificate that ACS will use to sign tokens. This is the basis of the trust relationship between your app and ACS. If you change that number, it means the trust is broken.
   
7. The next thing you have to do is replace the default AccountController with one that works when the authentication is outsourced of the app. Download the AccountController.cs, change the namespace to yours and replace it. Among other things, this controller will have an action called IdentityProviders that will return from ACS the list of identity providers in JSON format.

   public ActionResult IdentityProviders(string serviceNamespace, string appId)
   {
       string idpsJsonEndpoint = string.Format(IdentityProviderJsonEndpoint, serviceNamespace, appId);
       var client = new WebClient();
       var data = client.DownloadData(idpsJsonEndpoint);
   
       return Content(Encoding.UTF8.GetString(data), "application/json");
   }
   

Step 3. Using jQuery Dialog for the login box

1. In this last step we will use the jQuery UI dialog plugin to show the list of identity providers when clicking the LogOn link. Open the LogOnPartial cshtml file

   

2. Replace the LogOnPartial markup with the following (or copy from here). IMPORTANT: change the service namespace and appId in the ajax call to use your settings.

   @if(Request.IsAuthenticated) {
       <text>Welcome <b>@Context.User.Identity.Name</b>!
       [ @Html.ActionLink("Log Off", "LogOff", "Account") ]</text>
   }
   else {
       <a href="#" id="logon">Log On</a>
       <div id="popup_logon">
       </div>
       <style type="text/css">
       #popup_logon ul
       {
           list-style: none;
       }
       #popup_logon ul li
       {
            margin: 10px;
            padding: 10px
       }
       </style>
       <script type="text/javascript">
       $("#logon").click(function() {
           $("#popup_logon").html("<p>Loading...</p>");
           $("#popup_logon").dialog({ modal: true, draggable: false, resizable: false, title: 'Select your preferred login method' });
           $.ajax({
               url : '@Html.Raw(Url.Action("IdentityProviders", "Account", new { serviceNamespace = "YourServiceNamespace", appId = "https://localhost/<YourWebApp>/" }))',
               success : function(data){
                   dialogHtml = '<ul>';
                   for (i=0; i<data.length; i++)
                   {
                       dialogHtml += '<li>';
                       if (data[i].ImageUrl == '')
                       {
                           dialogHtml += '<a href="' + data[i].LoginUrl + '">' + data[i].Name + '</a>';
                       } else
                       {
                           dialogHtml += '<a href="' + data[i].LoginUrl + '"><img style="border: 0px; width: 100px" src="' + data[i].ImageUrl + '" alt="' + data[i].Name + '" /></a>';
                       }
   
                       dialogHtml += '</li>';
                   }
   
                   dialogHtml += '</ul>';
   
                   $("#popup_logon").html(dialogHtml);
               }
           })
        });
   
       </script>
   
   }

3. Include jQuery UI and the corresponding css in the Master page (Layout.cshtml)

   <link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
   <link href="@Url.Content("~/Content/themes/base/jquery-ui.css")" rel="stylesheet" type="text/css" />
   <script src="@Url.Content("~/Scripts/jquery-1.4.4.min.js")" type="text/javascript"></script>
   <script src="@Url.Content("~/Scripts/jquery-ui.min.js")" type="text/javascript"></script>
   

Step 4. Try it!

1. That’s it. Start the application and click on the Log On link. Select one of the login methods and you will get redirected to the right page. You will have to login and the provider may ask you to grant permissions to access certain information from your profile. If you click yes you will be logged in and ACS will send you a set of claims like the screen below shows.

   

   

I added this line in the HomeController to show all the claims:

ViewBag.Message = string.Join("<br/>", ((IClaimsIdentity)this.User.Identity).Claims.Select(c => c.ClaimType + ": " + c.Value).ToArray());

Well, it wasn’t 3 steps, but you get the point . Now, it would be really cool to create a NuGet that will do all this automatically…

Just for future reference, these are the claims that each identity provider will return by default

Facebook

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: 619815976
http://schemas.microsoft.com/ws/2008/06/identity/claims/expiration: 2011-04-09T21:00:01.0471518Z
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress: yourfacebookemail@boo.com
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: Matias Woloski
http://www.facebook.com/claims/AccessToken: 111617558888963|2.k <stripped> 976|z_fmV<stripped>3kQuo
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider: Facebook-<appid>

Google

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: https://www.google.com/accounts/o8/id?id=AIt<stripped>UoU
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress: yourgooglemail@gmail.com
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: Matias Woloski
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider: Google

LiveID

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: WJoV5kxtlzEbsu<stripped>mMxiMLQ=
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider: uri:WindowsLiveID

Yahoo

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: https://me.yahoo.com/a/VH6mn5oV<stripped>58mGa#e7b0c
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress: youryahoomail@yahoo.com
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: Matias Woloski
http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider: Yahoo!

Following up

Get the code used in this post from here.

If you are interested in other features of ACS, these are some of the things you can do:

• Read Vittorio’s post announcing ACS and pointing to lot of deliverables coming out today. This has been hard work from @nbeni, @sebasiaco, @litodam and more southies.
• Go through the ACSv2 labs in the Identity Training Kit
• Follow Vittorio’s blog, Eugenio’s blog, Justin’s blog and the AppFabric team blog
• Read articles like this
• I am collaborating with patterns & practices writing the second part of the Guide to Claims Based Identity and Access Control, including ACS and explaining the scenarios it enable. Stay tune at claimsid.codeplex.com for fresh content.

DISCLAIMER: use this at your own risk, this code is provided as-is.