Matias Woloski’s Blog

A typical scenario for an ISV that wants to create the "next application in the cloud" will be how to support identity federation with their customers (tenants). A common requirement I’ve heard is:

"I want to enable single sign on and allow enterprises that have their own STS to integrate with us. For companies that don’t have any identity infrastructure in place we want to allow them to login with an ubiquous credential like Windows LiveID. How do we do that without spending three months with a security guru?"

A possible answer is use Microsoft .NET Services Access Control. They enable that scenario in a very straightforward fashion. The following diagram shows a possible architecture that might fulfill the customer requirements. In this picture Southworks is an enterprise that has its own STS and Contoso doesn’t, hence they use Windows LiveID for their users. The good thing about this is that in the middle we have ACS acting as the "normalizer". It will receive tokens from LiveID and Southworks IP STS and will transform them to something Fabrikam knows (Roles, Actions, etc.).

If you are like me, you might be wondering how this all works. Here are the gory details of all the HTTP interactions of a WS-Federation passive profile "dance":

1. A user opening a browser
1. If he is at Contoso he browses to www.fabrikam-cloudapp.com/contoso (or contoso.fabrikam-cloudapp.com)
2. If he is at Southworks he browses to www.fabrikam-cloudapp.com/southworks (or southworks.fabrikam-cloudapp.com)
2. At the web site there is an Http Module or ActionFilter in ASP.NET MVC that will read the tenant alias from the route.
3. The module will construct the SignInRequestMessage federation message and will redirect to ACS (https://{solution-name}.accesscontrol.windows.net/passivests/{federation-endpoint}).
1. If it’s Southworks tenant we have to use the https://{solution-name}.accesscontrol.windows.net/passivests/Federation.aspx endpoint of ACS.
2. If it’s Contoso we have to use https://{solution-name}.accesscontrol.windows.net/passivests/LiveFederation.aspx in the endpoint of ACS.
   Note: these urls are not in any ACS documentation for now
3. The homeRealm (whr) parameter will tell ACS which IP STS to use (Contoso = login.live.com, Southworks = login.southworks.net which is a url Southworks provided at provisioning probably).
4. Finally, the realm parameter is fabrikam-cloudapp application. This will have to match with the scope you create on ACS (more on that below).
   Note: Look at the code at the end of the post to see how homeRealm and realm is used.
4. ACS will redirect the user to either LiveID or the company IP STS depending on the whr parameter
5. The user will login with LiveID cred or with other mechanisms if it’s a Geneva Server (user/pwd, kerberos, certs, cardspace, etc.)
6. A token will be issued and will be POSTed to ACS federation endpoint
1. [Contoso] In the case of LiveID you don’t have to do anything because ACS setup all the federation for us. LiveID will issue a token with one claim: the WLID email.
2. [Southworks] In the case of the company IP STS you will have to configure ACS as a relying party and supply its certificate to encrypt the token in your IP STS. In ACS you will have to create an Issuer and upload the company IP STS certificate. The company STS will issue the name claim and maybe groups or other claims.
7. ACS will read the token and apply the claim transformation (more on that below)
8. ACS will POST the token to www.fabrikam-cloudapp.com
9. Geneva Fx on the website will read the token, generate the ClaimsPrincipal and store it in a cookie for later usage.
10. Fabrikam can now authorize access to certain pages by reading the principal! either with IsInRole or for granular checks you could use Actions or a ClaimsAuthorizationManager

This is how ACS is configured for :

A better way to look at the table above is the following diagram:

Here we are using the Geneva Fx manually inside an ASP.NET MVC action filter. We use it manually because the multi tenancy nature that we want to implement does not allow to use the fixed values from the wsFederation configuration section.

   1: namespace FabrikamCloudApp.Web.Identity

   2: {

   3:     using System;

   4:     using System.Globalization;

   5:     …

   6:  

   7:     [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = false)]

   8:     public sealed class WSFederationAuthenticationFilterAttribute : ActionFilterAttribute, IExceptionFilter

   9:     {

  10:         public override void OnActionExecuting(ActionExecutingContext filterContext)

  11:         {            

  12:             var principal = Thread.CurrentPrincipal;

  13:  

  14:             if (!principal.Identity.IsAuthenticated)

  15:             {

  16:                 string realm;

  17:                 string homeRealm;

  18:                 string acsEndpoint;

  19:                 SignInRequestMessage message = null;

  20:                 

  21:         // retrieve tenant from url (http://…/{tenant})

  22:                 var tenant = (string)filterContext.RouteData.Values["tenant"];

  23:         

  24:         // lookup in some repository if the tenant setup a federation with its own sts

  25:                 if (IsLiveIDFederation(tenant)) 

  26:                 {

  27:                     acsEndpoint = "LiveFederation.aspx";

  28:                     homeRealm = "http://login.live.com";

  29:                 }

  30:                 else

  31:                 {

  32:                     acsEndpoint = "Federation.aspx";

  33:                     homeRealm = GetIdentityProviderUrl(tenant);

  34:                 }

  35:  

  36:                 realm = "http://www.fabrikam-cloudapp.com/";

  37:                 string issuer = "https://{solution-name}.accesscontrol.windows.net/passivests/{federation-endpoint}"

  38:                                 .Replace("{solution-name}", Configuration.FabrikamSolutionName)

  39:                                 .Replace("{federation-endpoint}", endpoint);

  40:  

  41:                 message = new SignInRequestMessage(new Uri(issuer), realm);

  42:                 message.Parameters.Add("whr", homeRealm);

  43:  

  44:         // redirect to ACS

  45:                 filterContext.Result = new RedirectResult(message.WriteQueryString());

  46:             }

  47:             else

  48:             {

  49:                 // we are back on our site, and we’ve got our token transformed to ClaimsPrincipal

  50:         var claimsIdentity = principal.Identity as IClaimsIdentity;

  51:  

  52:                 var tenantClaim = claimsIdentity.Claims.FirstOrDefault(c => c.ClaimType == Configuration.TenantClaimType);

  53:                 if (tenantClaim == null)

  54:                 {

  55:                     throw new HttpException(401, "Access is denied");

  56:                 }

  57:                 

  58:                 var fam = FederatedAuthentication.WSFederationAuthenticationModule;                                

  59:                 if (fam.CanReadSignInResponse(HttpContext.Current.Request, true))

  60:                 {

  61:                     SecurityToken token = fam.GetSecurityToken(HttpContext.Current.Request);

  62:                     SessionSecurityToken sessionToken = new SessionSecurityToken(principal as IClaimsPrincipal, token);

  63:                     fam.SetPrincipalAndWriteSessionToken(sessionToken, true);

  64:                     

  65:                     filterContext.Result = new RedirectToRouteResult(

  66:                                                         "DefaultRoute",

  67:                                                         new RouteValueDictionary(new { tenant = tenantClaim.Value }));

  68:                 }                

  69:             }

  70:         }

  71:         

  72:     }

  73: }

And just put this attribute on your entry point Controller:

   1: public class HomeController 

   2: {

   3:     [WsFederationAuthenticationFilter]

   4:     public void Index()

   5:     {

   6:     }

   7: }

I can tell my customer "sure, we can implement this. It’s only 73 lines of code and some configuration here and there"

Happy Federation!

Couple of weeks ago Ryan Dunn announced Azure Issue Tracker. From this post:

"This sample application is a simple issue tracking service and website that pulls together a couple of the Azure services:  SQL Data Services and .NET Access Control Service."

I’ve been working with Ryan and other guys at DPE and Southworks to put together this sample before PDC. With all the back and  forth (the .NET services were not working as reliable as they work now) we were not able to pull it through at that time. Well, it’s now live and you can download the source code. Some of its features:

• [Identity] .NET Services Access Control as a relying party and claims transformation STS
• [Identity] Federation against LiveID and claim mapping between email -> tasks. I hinted the implementation in these post.
• [Identity] Claims aware application and service layer (by doing identity delegation with ActAs)
• [Data] Storage on SDS using the flexible schema to extend the data model of the issue
• [General] Multi tenancy at all levels (identity, data, programming model)
• [General] Clean separation of concerns using ASP.NET MVC, Geneva Framework, WCF and WF.

This is the standard edition. The enterprise edition is coming with features related to manageability (Management API, Powershell CmdLets, MMC, SCOM, etc.) and identity federations against third party STS. Stay tuned!

Download the code

In the previous post I introduced a scenario where you can use .NET Services Access Control and Windows LiveID to delegate authentication and authorization. In this post we will go through the different pieces needed in the application to perform authorization checks. First thing will be configure the passive federation using Geneva on the application and later we will create an ASP.NET MVC action filter to perform the access check against the incoming claims.

Note: all the code showed here is using Microsoft Identity Framework "Zermatt" Beta 1. The new Geneva Framework might have some changes.

Configuring passive federation on the website

Configure passive federation on the website is about defining which SAML token version we will accept and the certificate we will use to decrypt the incoming token. The following configuration uses Zermatt Beta 1, so this probably changes on Geneva.

<microsoft.identityModel>
    <tokenHandlers>
      <remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11TokenHandler, Microsoft.IdentityModel, Version=0.4.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11TokenHandler, Microsoft.IdentityModel, Version=0.4.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <samlSecurityTokenRequirement>
          <allowedAudienceUris>
            <add value="http://localhost/YourApp/" />
          </allowedAudienceUris>
        </samlSecurityTokenRequirement>
      </add>
    </tokenHandlers>
    <federatedAuthentication enabled="true">
    </federatedAuthentication>
    <serviceCertificate>
      <certificateReference findValue="01 20 …" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
    </serviceCertificate>
  </microsoft.identityModel>

When the user click on the sign in button, the link will point to to the .NET Services Access Control passive STS url. The following method uses Geneva to generate this WS-Federation url.

private static string GetFederationUrl(string realm, string issuer, string homeRealm, string returnUrl)
{
    FederatedAuthenticationModule fam = new FederatedAuthenticationModule();
    fam.Realm = realm;
    fam.Issuer = issuer;
    fam.Reply = returnUrl;
    SignInRequestMessage signInMsg = fam.CreateSignInRequest();
    signInMsg.Parameters.Add("whr", homeRealm);
    string url = signInMsg.WriteQueryString();
    return url;
}

The following code and configuration will give you an idea of the url that is being built. Pay attention to this url because a small change might break the whole thing.

string url = GetFederationUrl(ConfigurationManager.AppSettings["AccessControlRealm"],
                            ConfigurationManager.AppSettings["AccessControlIssuer"],
                            ConfigurationManager.AppSettings["AccessControlHomeRealm"],
                            replyTo);

<!– Windows Azure Federation –>
<add key="AccessControlRealm" value="http://localhost/YourApp/"/> <!– should match to a scope –>
<add key="AccessControlIssuer" value="https://accesscontrol.windows.net/passivests/yoursolution/LiveFederation.aspx"/>
<add key="AccessControlDefaultReply" value="http://localhost/YourApp" />
<add key="AccessControlHomeRealm" value="http://login.live.com" />

The AccessControlRealm config is important because it will match the scope on your solution. You will have to configure the scope to encrypt with the public key of your website certificate and create the claim mappings from Windows LiveID to your well known claims. If you don’t have the scope created or configured to output at least one claim you will get a 403 Forbidden on the .NET Services Access Control STS.

Performing access check in the web site

Now that we have everything configured and the token should be coming back to our website, it’s time to do the access check. By using Geneva, the token will be transformed to a Principal object and it will be accessed through the ClaimsPrincipal static class. On the other hand, ASP.NET MVC allow us to plug into the action execution pipeline and get access to the context data like route values. The following code shows an ActionFilterAttribute that will grab the claims from the the Geneva ClaimsPrincipal and will call a strategy class that will perform the access check. If the access check is not successful, the filter will render a NotAuthorized view.

namespace YourApp.Identity
{
    using System;
    …

    public class ClaimAuthorizationRouteFilterAttribute : ActionFilterAttribute
    {
        public ClaimAuthorizationRouteFilterAttribute(string[] operations)
        {
            this.Operations = operations;
        }

        public string[] Operations { get; set; }

        public override void OnActionExecuting(ActionExecutingContext context)
        {
            var identity = ClaimsPrincipal.Current.Identity as IClaimsIdentity;
            var claims = identity.Claims.ToArray();
            var routeData = context.RouteData.Values.ToArray();
            var strategy = CreateAuthorizationStrategy();
            var executionContext = new ExecutionContext()
            {
                ClaimsNeeded = Operations,
                OperationContextData = routeData,
            };

            if (!strategy.IsAuthorizedFor(executionContext, claims))
            {
                context.Result = new ViewResult
                {
                    ViewName = "NotAuthorized"
                };
            }

            base.OnActionExecuting(context);
        }

    }
}

Finally, the following code shows an implemented strategy for a multi tenant application that manage projects.

namespace YourApp.Identity
{
    using System.Linq;
    using System;

    public class StandardAuthorizationStrategy : IAuthorizationStrategy
    {
        private const string ProjectClaimType = "urn:Project";
        private const string TenantClaimType = "urn:Tenant";
        private const string OperationClaimType = "urn:Operation";

        public bool IsAuthorizedFor(ExecutionContext context, Microsoft.IdentityModel.Claims.Claim[] claims)
        {
            bool authorized = true;
            var tenantClaim = claims.SingleOrDefault(c => c.ClaimType == TenantClaimType);
            var operationClaims = claims.Where(c => c.ClaimType == OperationClaimType);
            var projectClaims = claims.Where(c => c.ClaimType == ProjectClaimType);
        var tenant = context.OperationContextData["Tenant"].ToString();
        var project = context.OperationContextData["Project"].ToString();

            if (!string.IsNullOrEmpty(tenant))
            {
                authorized &= tenantClaim.Value.Equals("*", StringComparison.OrdinalIgnoreCase) ||
                              tenantClaim.Value.Equals(tenant, StringComparison.OrdinalIgnoreCase);
            }

            if (!string.IsNullOrEmpty(project))
            {
                authorized &= projectClaims.Where( p => p.Value.Equals("*", StringComparison.OrdinalIgnoreCase)).Count() > 0 ||
                              projectClaims.Where( p => p.Value.Equals(project, StringComparison.OrdinalIgnoreCase)).Count() > 0;
            }

            if (context.Operations != null)
            {
                bool temp = true;
                foreach (string op in context.ClaimsNeeded)
                {
                    temp &= operationClaims.Where(o => o.Value.Equals(op, StringComparison.OrdinalIgnoreCase)).Count() > 0 ||
                            operationClaims.Where(o => o.Value.Equals("*", StringComparison.OrdinalIgnoreCase)).Count() > 0;
                }
                authorized &= temp;
            }

            return authorized;
        }
    }
}

The only thing left is to put an attribute above the action. The following attribute specifies that the New action will be executed if the incoming token contains the following "urn:Operation" claims.

public class ProjectsController : Controller
{

        [ClaimAuthorizationRouteFilter(new string[] {
                                            "AddUser",
                                            "AddUsersToProject",
                                            "CreateProject" })]
        public ActionResult New() {
        ….

    }

    …

}

So if a user browses to: http://yourapp/Contoso/Projecsts/New, the filter will call the strategy that will check:

• if the user contains a tenant claim with the value "Contoso" (taken from the route data)
• if the user contains three operation claims: AddUser, AddUsersToProject and CreateProject

And if a user browses to: http://yourapp/Contoso/Projecsts/some-project/Edit, the filter will call the strategy that will check:

• if the user contains a "tenant" claim with the value "Contoso" (taken from the route data)
• if the user contains the "operation" claims specified in the Edit action
• if the user contains a "project" claim with the value "some-project"

The work we did through the last couple of months is materialized now. James Conard and the DPE team (Nigel Watling, Ryan Dunn, Vittorio Bertocci, Drew Robbins, et al) were able to hit the road before anyone else at Microsoft by releasing the Azure Services Training Kit.

I was walking through the Hands On Labs lounge today, watching at people doing lines to do the labs.

The kit includes labs on:

• SQL Data Services
• Windows Azure
• .NET Services Service Bus
• .NET Services Access Control
• .NET Services Workflow

You will need an invitation code, but you will be able to read the document and code to get lots of information.

Download it now

My interest in Software as a Service (SaaS) born during a trip to Microsoft in 2006. Looking for an interesting topic to elaborate on my graduate thesis, I started digging on different areas and asking different colleagues and friends. Initially, influenced by the work of Arvindra Sehmi, I got interested in agent programming (BDI agents, multi-agents systems, etc). Later, Eugenio Pace, a mentor and friend, commented me about an emerging model of software distribution. After a couple of months, Alejandro Jack (mentor and friend also), contacted me with John DeVadoos (former director of the Architecture Strategy Team at Microsoft, now leading the patterns & practices team). This group was formed by Gianpaolo Carraro and Fred Chong initially and last year Eugenio joined them and Fred left. Their daily job consists of researching the Software as a Service model from the architectural point of view. As part of this challenge, the group establishes relationships with clients interested in the model and with product teams looking for feedback to shorten the gap on the platform. The group also publishes a number of papers and proof of concepts using Microsoft technologies. I did a good connection with them and finally decided to pick Software as a Service as the topic for my thesis.

Throughout the last two years I’ve been collaborating with this group writing proof of concepts, preparing and delivering workshops. On the right, it’s me working with Eugenio (on the left) at building 20 one year ago (Gianpaolo is taking the picture). The post-its on the wall are the user stories for Northwind Hosting (I was happy to see Google App Engine six months later as a validation of our thinking).

I’ve witnessed the growth of Software as a Service since it was in the initial stages up to now that has started being adopted by the industry and lately has been extended to a broader term: Cloud Computing.

The thesis is the sum of all the experience I gather along these years and it’s an attempt to summarize and compress the taxonomy of Software as a Service applications on a single model; that is more about “breadth” than “depth”. This model was based on Feature Modeling, a technique used in Software Product Lines (SPL). Feature Modeling is a method and notation to elicit and represent common and variable features of the system in a system family. It was first proposed by Kang et al in Feature Oriented Domain Analysis by the Software Engineering Institute (SEI, 90). It’s been used lately in Generative Software Development (Czarnecki, 2005), which aims at modeling and implementing system families in such a way that a given system can be automatically generated from specification written in one or more textual or graphical domain specific languages (DSLs). Since SaaS and Cloud Computing are evolving fast I wanted to separate the problem space from the solution space allowing the individual development and growth of each of them. Feature Modeling helped because it was focused on the capabilities. I didn’t try to use Feature Modeling to automate the generation of this kind of systems, though. The priority was having a model that allow me to frame and explain Software as a Service systems.

Separation between problem and solution space (Overview of Generative Software Development, Czarnecki)

Part of defining the problem space consisted of doing a domain analysis. This is an activity of SPL aiming to characterize a domain by understanding their commonality and variability. If you follow this blog you might have read the cloud computing taxonomy map post. That was an exercise during the domain analysis that helped me understand the different scopes, offerings and features of Software as a Service.

Domain analysis of Software as a Service

With this information, I’ve spent a couple of days pasting post-its on the wall, trying to group the features and capabilities in a way that makes sense. The end result was this “onion” diagram where each category holds the different features of Software as a Service.

The model is later refined, from the taxonomy above to the capability layer (problem space) and finally to the implementation layer (solution space) as shown in the following figure.

The thesis then describes each of the capabilities in a high level fashion and then proposes patterns, architecture styles and technologies to implement those capabilities.

The following feature tree is an instance of the capability layer of the model for the LitwareHr application (grayed capabilities are not part of LitwareHr system). This content is in Spanish, but it will be soon available in English.

The thesis also includes other non technical aspects like

• Adoption and diffusion analysis of SaaS based on market research
• Barriers for adoption
• Historical context (starting from specialization in the 19th century, passing through outsourcing, mainframes and what not
• Roles and ecosystem

I want to thanks again to all the people that helped directly or indirectly: my family and fiancee, Alejandro Jack, Gustavo López, Eugenio Pace, Gianpaolo Carraro, Fred Chong, Arvindra Sehmi, Ariel Schapiro, Angel “Java” Lopez and to all Southworks.

Fell free to download the Spanish version and let me know if you find it useful to matias at southworks dot net.

Lately the term SaaS became a broader term and now it is called Cloud Computing (see David Chappell’s paper and Wikipedia). It includes the whole paradigm of utility computing + saas + platform as a service + * as a service.

I’ve got good feedback on the taxonomy map from the blogsphere (including Jeff Kaplan, from THINK IT Services). I updated the map some time ago but didn’t have time to publish. So here it is rather sooner than later. (I need Pablo’s help to do the animated GIF, so this time is static)