Fast forward to May this year, I’m happy to disclose the proof of concept we did with the Microsoft Federated Identity Interop group (represented by Mike Jones), Medtronic and PayPal. The official post from the Interoperability blog includes a video about it and Mike also did a great write up. I like how Kim Cameron summarized the challenges and lessons learnt of this PoC:

The change agent is the power of claims.  The mashup Mike describes crosses boundaries in many dimensions at once:

• between industries (medical, financial, technical)
• between organizations (Medtronic, PayPal, Southworks, Microsoft)
• between protocols (OpenID and SAML)
• between computing platforms (Windows and Linux)
• between software products (Windows Identity Foundation, DotNetOpenAuth, SimpleSAMLphp)
• between identity requirements (ranging from strong identity verification to anonymous comment)

The business scenario brought by Medtronic is around an insulin pump trial. In order to register to this trial, users would login with PayPal, which represents a trusted authority for authentication and attributes like shipping address and age for them. Below are some screenshots of the actual proof of concept:

While there are different ways to solve a scenario like this, we chose to create an intermediary Security Token Service that understands the OpenID protocol (used by PayPal), WS-Federation protocol and SAML 1.1 tokens (used by Medtronic apps). This intermediary STS enables SSO between the web applications, avoiding re-authentication with the original identity provider (PayPal).

Also, we had to integrate with a PHP web application and we chose the simpleSAMLphp library. We had to adjust here and there to make it compatible with ADFS/WIF implementation of the standards. No big changes though.

We decided together with the Microsoft Federated Identity Interop team to make the implementation of this STS available under open source using the Microsoft Public License.

And not only that but also we went a step further and added a multi-protocol capability to this claims provider. This is, it’s extensible to support not only OpenID but also OAuth and even a proprietary authentication method like Windows Live.

DISCLAIMER: This code is provided as-is under the Ms-PL license. It has not been tested in production environments and it has not gone through threats and countermeasures analysis. Use it at your own risk.

Project Home page
http://github.com/southworks/protocol-bridge-claims-provider

Download
http://github.com/southworks/protocol-bridge-claims-provider/downloads

Docs
http://southworks.github.com/protocol-bridge-claims-provider

If you are interested and would like to contribute, ping us through the github page, twitter @woloski or email matias at southworks dot net

This endeavor could not have been possible without the professionalism of my colleagues: Juan Pablo Garcia who was the main developer behind this project, Tim Osborn for his support and focus on the customer, Johnny Halife who helped shaping out the demo in the early stages in HTML :), and Sebastian Iacomuzzi that helped us with the packaging. Finally, Madhu Lakshmikanthan who was key in the project management to align stakeholders and Mike who was crucial in making all this happen.

Happy federation!

My short answer is that there aren’t solutions that scale or doesn’t scale. The scalability is a quality attribute of a system and it varies depending on the context. A good system is the one that is easily adaptable to new contexts and a good solution is the one that is the most convenient in a local context.

Putting things in context

So here is the analysis of the solution proposed and the context where it might applies.

I used the following parameters in the calculation:

• Time to dequeue 32 messages at a time: 1600 milliseconds (source)
• Time spent notifying ASP.NET cache the dependency changed: 300 milliseconds (this is a worst case scenario, it is actually in the nanosecs scale)

Some conclusions you can take from this

• From 1 to 1000 items updated per second (i.e. items invalidated) there is a penalty of 3 minutes (in the worst case) to invalidate the cache of those 1000 items. We are talking about items invalidated PER SECOND. Even having 1 update per second is a lot, in certain systems, so this seems to be good enough for many applications.
• Passing the 1000 items barrier, the time to invalidate all the cache items could be unacceptable (e.g.: you don’t want to wait hours to invalidate the cache). However, if you have more than 1000 updates per seconds, you are probably having other problems

So what is the drawback compared to a distributed cache?

If you compare this solution to something like memcached, the main difference resides when you have lots of web servers in a farm. This is because memcached will replicate and keep synchronized the cache items between nodes. So when you insert an item in memcached it is available to all the web servers almost immediately. However, when using the ASP.NET Cache and the cache dependency mechanism, when the item is invalidated, EACH web server will have to retrieve the item again and insert it in the cache. Retrieving the resource is the expensive operation, but not invalidating the cache.

I hope this clarifies a bit what I meant by “poor man’s memcached”

Part of working with the Windows Azure guidance team is not only about writing but it’s also about helping customers and understanding real life problems. This help us validate and enrich the content.

One of the customers we are helping has an hybrid solution in Windows Azure where there is a backend running on-premises that pushes information to a frontend running on Windows Azure in ASP.NET. This information is stored in blob storage and then served from the web role. To avoid going every time to the blob storage, though, they want to cache the information. But whenever you cache, you have to handle the expiration of the item you are caching, otherwise it never gets updated. That’s one option, cache it for X minutes. But the ideal would be to control the caching and whenever the information gets stale, update the cache. This is easy if you use an ORM like NHibernate or if you are using SqlCommands and SqlCacheDependency or if you use something like memcached or the AppFabric velocity. However it gets more difficult if you have other kind of resources to cache and if the web application runs in a farm.

Using Windows Azure queues to invalidate ASP.NET Cache

Maybe you need something smaller. This is what I implemented, I just posted on git two classes that can be used in a Windows Azure Web Role running ASP.NET as a very basic distributed caching mechanism. The following picture shows how it works at a high level.

Usage

Using it requires two things

1. Start the monitor (that listens to the queue). Write this code either in the WebRole entry point or in the Global.asax Applicaiton_Start.

   

2. Use the regular ASP.NET Cache API but providing the CloudQueueCacheDependency with a key

   

Example

I uploaded this to Windows Azure and provisioned two instances of a web role and this is the result

Web Role instance 0	Web Role instance 1

By sending a message to the invalidatecache-distributedcache-web-in-0 queue we invalidate the item “test” in cache in the 0 instance. This corresponds to the Cache1 label. If we send “test2” message, we would invalidate the Cache2 item.

The cache expired and an updated datetime is shown.

Web Role instance 0	Web Role instance 1

Conclusion

By using this technique you can have a distributed system where the backend makes an update on-premises, pushes something to the cloud and it invalidates the cache by posting a message to a queue. I didn’t worry too much about being fault tolerant in the monitor simply because in the worst case the item keeps alive in the cache and you can repost a message.

Download the code from here

DISCLAIMER: the code is provided as-is and has not been tested under stress conditions. Use it at your own risk.

We will be presenting 3 different scenarios and how we approached them using Federated Identity (ADFS and Windows Identity Foundation) and Cloud Computing (Windows Azure and Amazon EC2). We will talk about the architecture behind, involving an ADFS acting as a Federation Hub, the notion of different level of trusts/assurance and the inclusion of social identity providers like Facebook, Yahoo, LiveId, Twitter, etc.

The solution shows

• A web site hosted on Windows Azure that is something like “Federated SkyDrive” where a user can assign cross-organization permissions based on email, group and organization claim.
• Organizations plugged to the hub using identity providers like ADFS, CA SiteMinder or PingFederate
• Other organizations plugged to the hub using social identity providers like Facebook, Yahoo, Google, Twitter, LiveID
• Different level of trusts depending on the identity provider that issued the token
• Multiple cloud computing providers like Amazon EC2 hosting an ADFS v2 and Windows Azure hosting the website

The scenario and architecture used is similar to the one we described in the Federation with Multiple Partners chapter of the Claims-Based Identity and Access Control guide from patterns & practices. The guide was key to help some of the stakeholders understand the concepts and artifacts of the solution.

With the advent of the cloud, the need of collaborating fast and securely between organizations in a cost effective way, these kind of concepts and architectures should become the de-facto solution. Looking forward to that future!

var claims = new[]
    {
        new Claim("foo", "3"),
        new Claim("foo_bar", "true"),
        new Claim("foo_baz", "Ted"),
        new Claim("http://schemas.travisspencer.com/2010/05/test/claims/shoesize", "11"),
        new Claim("http://schemas.travisspencer.com/2010/05/test/claims/haircolor", "blond"),
        new Claim("Age", "16"),
    };
    var identity = new ClaimsIdentity(claims);
    dynamic user = new MyGoodUser(identity);
    Console.WriteLine("Foo = {0}", user.Foo);

Now, If you look carefully most of the claims are defined with a long namespace plus a friendly name, like:

So wouldn’t it be nice if I could do something like

Thread.CurrentPrincipal.AsClaims().GivenName
Thread.CurrentPrincipal.AsClaims().HomePhone

Well, I took Travis code and tweaked here and there and here is how it looks:

This is user experience applied to the API I like to call it DX (Developer Experience).

I posted the code here

http://pastie.org/991525

Ryan covered pretty much of the features in this 15 minutes screencast, so I will focus on the extensibility of the Windows Azure MMC.

The Windows Azure MMC has the following extensibility points:

• Adding a new module (i.e. a new node somewhere in the tree)
• Adding a new diagnostic data viewer
• Adding a new table storage viewer

One of the pieces that we enjoyed building with Sebastian (aka Iaco) was the diagnostics data analysis. This functionality allows you to work with the data generated by the Windows Azure diagnostics infrastructure and it’s built using MEF and the MVVM pattern. If you want to create your own visualizer or viewer for diagnostic data, keep reading….

How to implement a diagnostics data viewer

We used MVVM pattern throughout the MMC (how we did that is long enough to write another blog post). So implementing a diagnostics plugin means in a few words: creating a ViewModel + UserControl, decorate the ViewModel with the ViewerExport attribute, derive from ViewerViewModelBase<UserControlType> and implement OnSearchAsync and OnSearchAsyncCompleted. These are the step by step instructions to do that. Download the code here: http://snipurl.com/mmcplugin

1. First, open Visual Studio 2008 or 2010 and create a new WPF User Control Library.

   

2. Add references to the following dlls (all of them located %install_dir%\WindowsAzureMMC\release)
• MicrosoftManagementConsole.Infrastructure
• Microsoft.Samples.WindowsAzureMmc.Model
• Microsoft.Samples.WindowsAzureMmc.ServiceManagement
• System.CompositionModel.Composition
  
   
3. Right click on the project and add a new class called “SimpleAzureDiagnosticsEventViewer” and decorate it with the following attributes 

   [PartCreationPolicy(CreationPolicy.NonShared)]
   [ViewerExport("Simple Datagrid Azure Logs", ViewerType.WindowsAzureLogsViewer)]
   public class SimpleAzureDiagnosticsEventViewer
   

4. Derive the class from ViewerViewModelBase<UserControl1> [1]. The viewers must implement the IViewer interface but we provide this base class that helps with some infrastructure code.

   public class SimpleAzureDiagnosticsEventViewer : ViewerViewModelBase<UserControl1>
   

5. Override the OnSearchAsync and OnSearchAsyncCompleted methods

   protected override System.Collections.IEnumerable OnSearchAsync(FilterCriteria criteria)
   {
   }

protected override void OnSearchAsyncCompleted(SearchCompletedEventArgs args)
{
}


6. Finally use the DataProvider [1] (service injected through the base class) to perform a search on the WindowsAzure Logs and fill the EventLogEntries collection (notice the RetrieveWindowsAzureLogsData)

public ObservableCollection<WindowsAzureLogData> EventLogEntries { get; set; }

public SimpleAzureDiagnosticsEventViewer()
{
    this.EventLogEntries = new ObservableCollection<WindowsAzureLogData>();
}

protected override System.Collections.IEnumerable OnSearchAsync(Microsoft.Samples.WindowsAzureMmc.Model.Diagnostics.Analysis.FilterCriteria criteria)
{
    return this.DataProvider.RetrieveWindowsAzureLogData(criteria);
}

protected override void OnSearchAsyncCompleted(SearchCompletedEventArgs args)
{
    bool noData = (args.Result == null) || (((IEnumerable<WindowsAzureLogData>)args.Result).Count<WindowsAzureLogData>() == 0);

    if (!noData)
    {
        var result = (IEnumerable<WindowsAzureLogData>)args.Result;
        foreach (var item in result)
        {
            this.EventLogEntries.Add(item);
        }
    }
}

7. Finally, put some XAML on the usercontrol bounded to the EventLogEntries collection. In this case we are using the WPF Toolkit datagrid. Notice the ItemsSource property bounded to EventLogEntries

<UserControl x:Class="SimpleDiagnosticPlugin.UserControl1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:toolkit="clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit"
    >
    <Grid>
        <toolkit:DataGrid AutoGenerateColumns="False" Name="EventsGrid" ItemsSource="{Binding EventLogEntries}"
                              Height="300" VerticalAlignment="Top" IsReadOnly="True">          
            <toolkit:DataGrid.Columns>
                <toolkit:DataGridTextColumn Header="Level" Width="Auto"  Binding="{Binding LogLevel}" />
                <toolkit:DataGridTextColumn Header="Message" Width="Auto" Binding="{Binding Message}" />
                <toolkit:DataGridTextColumn Header="Date and Time" Width="Auto" Binding="{Binding EventDateTime}" />
            </toolkit:DataGrid.Columns>
        </toolkit:DataGrid>
    </Grid>
</UserControl>


8. Compile and grab the output dll and copy to %install_dir%\WindowsAzureMMC\release.
9. If you have the MMC open, click on Refresh Plugins if not open it and browse to the diagnostics node.
   
10. Click on the Windows Azure Logs dropdown and the new plugin will appear. Select the new plugin and the search will start. The MMC will call the Search method of the IViewer which will end up calling OnSearchAsync with the filter defined.
     
      
11. If you choose Excel this is what happens

     

The user experience is probably not the best, we had to make it generic enough with the usual time constraints and the MMC UX constraints. Things can be much better, hopefully in a v3.

I will leave you with some food for thought…. how hard would be to create a plugin that mixes the perf data and event logs data?

[1] The ViewerViewModelBase class. Plugins should derive from it.

[2] The IDataProvider interface. The default implementation DataProvider is a wrapper over the diagnostics API that queries the diagnostics tables

Download the code of this simple plugin from http://snipurl.com/mmcplugin

• Manage access to employees that belong to the Active Directory
• Manage access to partners that has their own STS
• Manage access to certain webparts, doc libraries or lists through Sharepoint groups and claims
• Allow/deny access to Windows LiveID users

• Book content online on MSDN.
• Book PDF download
• Final samples download
• Discuss at Codeplex

Looking at my name in the cover of a book together with such a group of experts is really a significant milestone in my career. I want to specially thanks Eugenio for trusting me and inviting me to participate in this project. Hope you find the content useful. If you have any questions or you want to discuss about claims, identity, federation towards your next project feel free to mail me at matias at southworks dot net.

Now heading towards the second book: Cloud Guidance! Stay tuned…

Being part of the making of a PDC keynote was very interesting. We had meetings with Partner Architects and Distinguished Engineers of the different Microsoft product groups. You get to learn a lot about politics in those meetings ;).

Once again we worked closely with Vittorio on Windows Identity Foundation content which was RTMed. David and Ryan on Azure and Jonathan Carter on Tailspin among other things. Finally, thanks all the team @ Southworks for the great support pre-PDC.

On a related note, the last month we worked hard with Eugenio, Erwin, the team at patterns & practices, Fede Boerr, Keith, Dominick to deliver a printed preview of the Claims Based Identity & Access Control Guide. Limited copies were distributed on the WIF booth and p&p booth at PDC and the book was very well received. We’ll be soon reaching a milestone and publish the following chapters:

Well, I had to catch-up with the blog… hopefully will keep the pace now.

This is not a new topic as Eugenio suggests in his blog, but it’s getting more and more attention because:

• Technology is more mature, hence it’s easier to implement claim-based identity
• Enterprises are failing to control the amount of different identity repositories, leading to higher provisioning/deprovisioning costs, security problems, etc.
• End users want simpler user experiences and less passwords
• The cloud makes all these even more challenging

We started with this project a couple of weeks ago planning the content. The approach we decided to use was heavily driven by scenarios (aka zero bulls**t). We used the visual metaphor of a tube map with scenarios being the stations separated in two main lines:

• The blue one, the Enterprise track approaches the federated identity problem from the point of view of a company with many applications that wants to implement SSO and Federation. The main stations are SSO (within the enterprise), Federation (with partners), SOAP Web Services (and flow of identity across services), SSO with a third party cloud app and some variations like: what if the company decides to host an application on the cloud (namely Windows Azure); or what if the company needs to integrate with an application that talks SAML protocol (i.e. Salesforce, Google Apps)
• The yellow one, ISV track on the other hand tackle the problem from the perspective of an ISV that wants to offer an application as a service (think about Salesforce or Dynamics CRM Online as the canonical examples). In this track we start by explaining how to implement federated identity for a cloud application. Then we show how to automate federation to on board new customers. We also show things like exposing a REST API and how that plays with claims; how to integrate with LiveID (or OpenID) for small customers that don’t have an Identity Provider in place; and we end up explaining how to do auditing/billing with claims.

I’m very proud and excited about being part of such a great team including: Dominick Baier, Vittorio Bertocci, Keith Brown, David Hill and Eugenio Pace. I’m sure that something great will come up from this team, the board of reviewers and the community that will help to prioritize and keep the focus!