For some reason the slide deck I presented at Mix didn’t show up on the Mix 09 website. If you are interested in the deck, see the link below.

Today I caught up on some press material on Azure Services. For those that haven’t seen it, the picture version of Azure Services is below:

One article published in late February popped out at me: http://blogs.zdnet.com/microsoft/?p=2173.

Among other things, this article brings good questions regarding how aligned and integrated the Azure Services platform is today. A quote from the article:

“Our engineering efforts are fully aligned with Red Dog now,” said Shewchuk. “We expect them (Red Dog) to be available with a fully integrated developer experience” upon which CSD and its customers can count when working with .Net Services, SQL Data Services and other components.

To be clear, the end results of this engineering alignment aren’t fully apparent yet. As John indicates, we are working on it.

This week at Mix I demonstrated a new experimental client API (TokenClient) for interacting with the Access Control Service (ACS). The purpose of this API is to simplify the developer interaction with the ACS Security Token Service. It still uses WS-Trust on the wire, but restricts the WS-Trust options to what I believe to be the bare minimum.

NOTE: this code requires the Geneva Fx (version released at PDC 08) in order to work. The assembly version # is 0.5.1.0.

NOTE NOTE: This code is highly experimental – I’ve written it to demonstrate a core capability of ACS. As a result, it hasn’t been rigorously tested, and I am absolutely certain that there are bugs.

Recalling earlier posts, remember that ACS simply accepts claims and uses access control rules to transform those input claims to output claims. Claims in, Claims out – all the live long day. The client API shown here reflects that simplicity.

ACS receives “claims in” if those claims are wrapped in a token. As a result, the TokenClient type has a method that will package claims into a signed and encrypted token. There are other methods that send that token to ACS, and still other methods that return the ACS issued claims in a couple of different handy formats.

First let’s discuss instantiation. In order to create a token, a TokenClient object needs to be able to sign and encrypt a token. This information is packaged in a TokenClientSettings object. The TokenClient type constructor accepts a TokenClientSettings object as shown below.

TokenClientSettings settings = new TokenClientSettings() {

  LocalIssuerAddress = new Uri("http://localhost/myissuer"),

  LocalIssuerSigningCertificate = new X509Certificate2("sign.pfx", "pwd"),

  Scope = new Uri("http://localhost/myservice"),

  ScopeEncryptingCertificate = new X509Certificate2(“enc.cer", "pwd"),

  SolutionName = "justindemoaccount"

};

TokenClient client = new TokenClient(settings);

Next, let’s instantiate an IEnumerable<Microsoft.IdentityModel.Claims.Claim> object.

Claim[] claims = new Claim[] { new Claim(@"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", 

                                                     "justin@calculatordemo.com") };

This claim value is completely made up. It’s just a value that I’ve decided to use. Similarly, the claim type is fairly arbitrary. I chose UPN out of convenience – you can choose any claim type you like (as long as you set that claim type up in your ACS scope).

Next, let’s send those claims to ACS and see what claims we get back:

IEnumerable<Claim> acsIssuedClaims = client.TransformForClaims(claims);

Next, we can dump these claims to the console:

foreach (Claim claim in acsIssuedClaims) {

if (claim.ClaimType != "http://schemas.microsoft.com/ws/2008/06/identity/claims/confirmationkey")

{

     Console.WriteLine("===================================");

     Console.WriteLine("Claim Value: {0}", claim.Value);

     Console.WriteLine("\tClaim Type: {0}", claim.ClaimType);

     Console.WriteLine("\tClaim Issuer: {0}", claim.Issuer);

     Console.WriteLine("===================================\n");

}

}

Before we compile and run this sample, we need to setup ACS. The steps below roughly approximate what to do:

1) Login to the http://portal.ex.azure.microsoft.com and browse to the ACS management portal

2) Create a new scope (http://localhost/myservice)

3) Setup a new Identity Issuer:

a. Name: SimpleClaimIssuer

b. Uri: (http://localhost/myissuer)

c. Certificate (the public key only version of sign.cer)

4) Setup the encryption preferences:

a. Certificate (the public key verision of enc.cer)

5) Add a rule:

a. Input: UPN justin@calculatordemo.com

b. Output: Action: Read

When you press F5 in the project, you will see the Action claim print to the console. In essence, the TokenClient will have created a token that contains a UPN claim, sent it to ACS for transformation, received the result, decrypted and verified the result, and printed the claims to the console.

A link to download the code is below. Enjoy and please let me know as you find bugs… Again – this code is highly experimental…

The Geneva Framework FAM is the simplest way to experience ACS and ASP.NET. My friends in platform evangelism wrote a cool app that uses ACS, LiveID, and the Geneva Framework. It's called issuetracker, and I recommend checking it out: http://www.codeplex.com/azureissuetracker

My co-worker Jenny Lo wrote a good post on how to get started with .NET Services. If you are wondering how to get started this should do the trick.

https://blogs.msdn.com/jennylo/archive/2008/11/04/a-step-by-step-guide-from-creating-a-net-services-solution-to-running-the-multicast-sample.aspx

In my previous post I described at a high level a simple scenario that leverages the Access Control Service. Now I'd like to describe the interactions between messaging participants and the .NET Access Control Service.

Recall the scenario: a multi-tenant payroll application is running in the cloud - it uses the Access Control Service to simplify federation with enterprise identity providers and handle RBAC processing.

The interaction pattern for this scenario is shown below.

Step 0

Before using the ACS, the payroll app (called Relying Party in the diagram) must establish a trust with ACS. This is done via a public key certificate exchange. The Relying Party administrator or developer defines or obtains a certificate from the certificate authority of it's choosing, then uploads the public key certificate to ACS.

Step 1

Next, the Relying Party administrator or developer will define access control rules in ACS. As indicated in my earlier post, the content of the rules is up to the administrator or developer. When this step is completed, ACS is setup and ready for use.

Step 2

The requestor sends a request for a token (Request for Security Token or RST) to ACS. An RST almost always contains claims (eg username / password, or another token issued from an identity provider).

Step 3

ACS then checks the claims in the RST. It then uses the input claims to determine the claims that will be sent in the RST response (called RSTR). Consider a simple rule: (Input) Username foo –> (Output) Role Administrator. If the input claim is Username foo, then the output claim is Role Administrator. ACS simply chains these rules together and calculates the output claim set.

Step 4

After the output claim set is determined, the claims are packaged into a SAML token and returned to the requestor. The token is signed with the ACS certificate and encrypted with the certificate used in step 0. There’s a little more to it than that, because the RP has to be able to differentiate its ACS STS from other ACS STSs. This will surely be a subsequent topic.

Step 5

The requestor then sends the token to the Relying Party along with a payload of its choosing.

Step 6

Upon receipt of the token + payload, the Relying Party verifies / validates the token, checks the claims in the token, then processes the payload accordingly. Concretely this means that the Relying Party verifies the token signature & decrypts the token. If the token signature / encryption keys are OK, the Relying Party then checks the claims in the token. If that endpoint or operation on the Relying Party requires Administrative privileges, then the token must contain an Administrator claim. Think of it like a simple toll gate. If the correct claim is present, the call proceeds. If not, then the call fails.

Claims Transformer

At a high level, ACS receives input claims and transforms them into output claims. We simplify these types of transformations into rules, and provide customers the ability to define these rules on a portal or through a simple API.

To the already initiated claims disciples, the Access Control Service is a multi-tenant Resource STS. The behavior of each STS is determined by simple rules - the rules control how each STS transforms claims.

To those not already initiated in the claims methodology, the previous definition may seem a bit obtuse. If that's the case, then consider a simple scenario:

Background

Let's say you work for a software vendor (Foo) that sells a web application (how about employee payroll management) to businesses. You have an existing on-premise offering and an existing install base. This version of your software integrates with customer identity providers (e.g. Active Directory, Tivoli, etc.).

Customer administrators can allow other employees access to the payroll system - this is driven by group membership (e.g. Domain Users have access). Internally the application uses a set of pre-defined roles, and assigns permissions based on role membership. As an example, consider the following simple model:

Active Directory Group= HR Payroll --> Application Role = Administrator

Application Role = Administrator --> Permission = CreatePayroll

Application Role = Administrator --> Permission = PrintPayrollChecks

...

This approach is known as Role Bases Access Control (RBAC). It's very simple, powerful, and very common.

Given that Foo's existing offering is on-premise it works well. Initial setup requires some basic plumbing with a single on-premise identity provider and a bit of configuration by the application administrator.

The Winds of Change

Some of your existing customers and many prospects are asking for a hosted / cloud version of your payroll application. As your team considers options, it becomes apparent that a good long term approach is to modify the existing on-premise application to be multi-tenant. Modifying a single tenant application to be multi-tenant isn't a joke, but customers are demanding it, so you proceed.

One of the things your team realizes pretty quickly is that the RBAC model in the on-premise application has to change a bit. The core concept of mapping groups to roles to permissions appears to still be viable, but now there are multiple identity providers. Your application now has to be able to differentiate Bar Corporation Groups from Baz Corporation Groups.

Luckily most of the software vendors that sell identity providers have built versions of their identity providers that will expose groups and other identity attributes outside of the corporate LAN. I believe that Microsoft's offering in this area is outstanding (Geneva Server, Geneva Framework, Microsoft Services Connector and the Federation Gateway - see Kim Cameron's blog for fantastic details). Concretely, this means that the hosted, multi-tenant version of your application can federate with lots of different corporate identity providers.

The Access Control Service

There is still a problem, however. You'll have to add quite a bit of code to your application to accept and parse tokens from these identity providers. To top it off, you'll have to make it pretty flexible and configurable. This is where the Access Control Service shines. In a nutshell, it is a service that simplifies interactions with any standards based identity provider, and allows you to define rules that transform Groups to Application Roles to Application Permissions.

To put it another way, your application won't have to directly interact with any identity providers. It can trust tokens from the Access Control Service. The Access Control Service will handle the gory details of decrypting, verifying and parsing tokens, extracting Groups (or other identity attributes) from tokens, and mapping Groups to Application Roles to Permissions. The end result is a single sign-on experience for your customers, and a simplified code base.

Up next - the common interaction model of the Access Control Service & why claims disciples call it a claims transformer.

Today we announced the CTP release of .NET Services! For quite a while now, I have been working on this project. It's great to see it announced and to have customers use our services. .NET Services consist of three services: the Service Bus, the Workflow Service, and my personal favorite: The Access Control Service.

My focus has almost exclusively been on the Access Control Service, so expect it to be the main topic of this blog for quite a while. The Service Bus, Workflow Service, and the portals use the Access Control Service so I will likely spend some time on those as well.

In a nutshell, the Access Control Service allows you factor access control code into a manageable collection of rules. Combined with Geneva Server and the Geneva Framework, you can do things like map groups to roles, and roles to permissions.

Yesterday we released a new version of BizTalk Services (R12). Over the next few weeks I'll be updating my blog with descriptions of the identity related features we added in this release. For now I'd like to describe one of the most obvious changes to the way you create, view, and manage access control rules.

To explain what these modes do, let me first describe the changes we made. Here are a few of the key concepts:

1. Every Identity Service account owns a Security Token Service (STS).
2. An STS is composed of one or more scopes.
3. A scope contains zero or more access control rules.
4. An STS owner can grant another Identity Service account permission to edit the access control rules in a scope

2-4 are new. The messaging (also called relay) service uses these concepts. It has no Identity Service special privileges. It is using the same core features available to everyone else. The Messaging Service owns an STS and it defines a root scope of http://connect.biztalk.net/services/. When you create a new account (newaccount) in the Identity Service, the messaging service creates a new scope http://connect.biztalk.net/services/newaccount. The Messaging Service then grants (newaccount) the permission to edit access control rules in (and only in) that scope. This new account provisioning is done in a provisioning agent that uses our public API.

Newaccount can also create a scope within that scope (like  http://connect.biztalk.net/services/newaccount/newestscope). NewAccount can then grant another IdentityService account permission to edit access control rules within that scope.

The behavior here is functionally similar to what an ISV might want (allow one of their customers to define access control rules for their “chunk” of the service).

It is important to note that the access control rules that belong to the scope http://connect.biztalk.net/services/newaccount are owned by the Messaging Service. NewAccount does not own the rules, it has just been granted permission to edit rules within that scope.

When designing the UI we wanted the experience of editing access control rules in a scope owned by another account to be distinct from the experience of editing access control rules in scopes you own. Our first attempt at drawing this ownership boundary is to set the default UI mode to show only the scopes you own. We called the default mode “Basic”. The mode that provides visibility into scopes owned by other accounts is called “Advanced”. In short, if you want to work with the access control rules in the messaging service scope (or the workflow scope), you can switch the mode to “Advanced” (shown below).

In keeping with the traditions of BizTalk Services, we love feedback – let us know what you think…

One of the little known features of BizTalk Services is it's support for metadata. There's a sample in the SDK (default path: C:\Program Files\Microsoft BizTalk Services SDK\Samples\Communication\ExploringFeatures\Metadata\MetadataExchange\CS30) that shows you how to listen for incoming metadata requests through the relay. It tracks with the WCF metadata story and is built on WCF extensibility points. In fact, if you open the machine.config file, you will see the policy importers and the WSDL extensions.

The end user experience is quite simple. At some point, you setup the service behavior

<behaviors>
  <serviceBehaviors>
     <!-- Application Behaviors -->
     <behavior name="serviceMetadata">
       <serviceMetadata />
     </behavior>
   </serviceBehaviors>
</behaviors>

Next you define an endpoint - (Notice the binding is the RelayBinding and not the normal metadata binding.)

<endpoint name="MexEndpoint"
          contract="IMetadataExchange"
          binding="relayBinding"
          bindingConfiguration="default" 
          address="mex" />

That's about all that's required to expose metadata.

Consuming it is just as easy. From a new VS project, all you have to do is right click the project and select "Add Service Reference" (VS 2008).

In the next window, enter the service bus URI (like sb://connect.biztalk.net/services/justinjsmith/Echo) and click Go:

When you click OK, the tooling (think svcutil) will generate the proxy code and config for you. In an empty project, literally the only two lines of code you have to write are:

EchoContractClient client = new EchoContractClient();
Console.WriteLine(client.Echo("hi there"));

This week I started a new job at Microsoft - I've moved from Developer and Platform Evangelism to the Connected Systems Division. I'm now a program manager on the BizTalk Services team (http://biztalk.net). It was hard to leave DPE, but this seems like the right opportunity. For those that haven't seen BizTalk.net, it's an incubation project for messaging, security, and workflow services that run at scale in Microsoft's hosted environment.

The week was a whirlwind, and I am having a blast. The team is very agile, and it has the atmosphere of a startup. Truly cool.

I just posted a new screencast on Channel 9: http://channel9.msdn.com/Showpost.aspx?postid=386824.

It's purpose is to show off the power of claims and claims transformation, especially in a hosted service like BizTalk Services.

The identity provider in BizTalk Services is a way for applications to delegate identity and access control to a hosted service. In other words, an application can use BizTalk Services to answer the all-important question "Who are you and what are you allowed to do?". If you haven't checked it out, I strongly recommend it (http://biztalk.net).

The identity provider can be used without the connectivity service. The calculator sample in the SDK is an example (as of R10, it installs by default in the C:\Program Files\Microsoft BizTalk Services SDK\Samples\AccessControl directory). This entry examines the calculator sample that uses a certificate, and this blog post is not a substitute for reading the readme...

As indicated in the readme, running this sample requires you to login to http://biztalk.net, go to "Manage Access Control", "Rules", and setup a few claims mappings. After you login, click on the following (right hand side):

The Rules link takes you to a page that lets you map input claims to output claims. In the case of the Calculator sample, you are going to map BizTalk.NET usernames to Resource+Operation claims. These Resource+Operation claims are demanded by the calculator service (running on your machine). WCF shields you from quite a bit of the protocol level goo here. The following is an example of what it looks like in the web UI:

There's lots of interesting things going on here. For now, let me just focus on the Output Claim Value field. It's the concatenation of (in this case) the service URL, "#", the service contract name, ".", and the action of the operation:

<Value> ::= <Service Url> "#" <Service Contract Name> "." <Operation Action>

This may sound very scientific, but the reality is that it's simply a matter of a choice made by the ServiceAuthorizationManager derived type that's included in the Calculator sample (available at C:\Program Files\Microsoft BizTalk Services SDK\Samples\AccessControl\CalculatorServiceWithCertificate\FederatedAccessManager). You can change it to be whatever you want (of <Read> or <Write> could have been substituted for contract name + operation action).

After you setup the input and output claim mapping for the calculator service, you have a system like the following:

Step 1: Present identity claims to BizTalk.NET

Step 2: Receive the claims that are mapped to that identity

Step 3: Send those claims to the Calculator Service

Step 4: If the claim (URL+ContractName+Action) is present, the ServiceAuthorizationManager allows the WCF infrastructure to invoke the calculator implementation.

In effect, the calculator service delegates identity and access control to BizTalk Services.

I think that's way cool.

A little while ago I ran into an interesting set of errors that may be of interest to you. Consider the following service contract snippet:

[OperationContract]
[WebGet(UriTemplate="foobar/{value}")]
String GetData(String value);

If you add the enableWebScript behavior to an endpoint that is using the WebHttpBinding, you will see this exception when the ServiceHost starts:

System.InvalidOperationException: Endpoints using 'UriTemplate' cannot be used with 'System.ServiceModel.Description.WebScriptEnablingBehavior'.

The reason for this error is rooted in the origin of the enableWebScript behavior. One of it's design objectives was to simplify working with the ASP.NET AJAX stack (Javascript proxy, JSON messages, etc). The AJAX stack doesn't have the equivalent of the UriTempalte type. It simply puts parameters in query strings (gets) and constructs entity bodies (posts). This is the default behavior of the WCF stack when the WebGet / WebInvoke annotations do not have a value for UriTemplate. Since any value of UriTemplate would be incompatible with the ASP.NET AJAX stack, we throw when it's present.

If you want JSON messages from a contract and you want to use the UriTemplate niceness, you can change your contract to:

[OperationContract]
[WebGet(UriTemplate="foobar/{value}", ResponseFormat=WebMessageFormat.Json)]
String GetData(String value);

Then, instead of using the enableWebScript behavior, use the WebHttpBehavior. You'll lose compat with the ASP.NET AJAX client stack (and the JS proxy), but you have the URI you are looking for.

The same is true if you are using the WebInvoke attribute and any HTTP method other than POST. The AJAX client stack only knows GET and POST...

I'm not prone to publish non-techie topics on this blog, but I can't help this one :). I'm often asked what life is like at Microsoft, and this video pretty much sums it up...

http://on10.net/blogs/tina/Life-At-Microsoft/