Problem with the Azure Services Training Kit’s IntroAccessControl Hands-on Lab

The Azure Service Training Kit’s April Update offers a series of hands-on labs (HOLs), which include “Introduction to the .NET Access Control Service” (a.k.a. IntroAccessControl). Its documentation (in \AzureServicesKit\Labs\IntroAccessControlService\Lab.html\html\) includes an overview, which describes the purpose of the HOL:

This introductory hands-on lab will walk you through the configuration as recognized issuer of a sample third party, FederatedIdentity.net (a [Microsoft] site used for interop testing with other identity management stacks); then it will demonstrate how to leverage claims transformation rules for implementing a simple but extremely effective access control strategy, one that in a more traditional scenario would entail a significant amount of resources.

Exercise 0 takes you through the process of creating a new .NET Services and SQL Services solution and changing your password for the solution.

Exercise 1 explains how to use Managed CardSpace Information Cards with the .NET Access Control Service (ACS) by creating an Identity Provider and Security Token Service (IP-STS) with default input claims (UserID, FirstName and LastName) and transformations to output claims (Listen, Send and Manage Actions). The CardSpace card authenticates the user to the Echo Service, a simple Windows Communication Foundation (WCF) Web service, and authorizes the user to invoke the Echo() method.

•• Updated May 4, 2009: Vittorio Bertocci (a.k.a. Vibro) provided a detailed response to my thread in the Problem with the Azure Services Training Kit’s IntroAccessControl Hands-on Lab thread added to the Windows Azure > .NET Services - Technical Discussions forum. Vittorio set me straight on the different claim requirements of the service publisher and consumer. I incorrectly assumed that because the publisher required the UserName/Password, the consumer would too.

• Updated May 3, 2009: Problem with the Azure Services Training Kit’s IntroAccessControl Hands-on Lab thread added to the Windows Azure > .NET Services - Technical Discussions forum and see comment added to Note below.

---

Problem Description:

I believe there’s a problem with the instructions for adding a new custom input claim type (Group = Domain Users. This is a claim that the user presenting the CardSpace card), which is to satisfy a rule that the user must satisfy claims to ownership of a specified ACS solution and to be a member of the Active Directory Domain Users group to invoke the Send action with which the Web service client invokes the Echo() method. The user proves ownership of the ACS solution (oakleaf-acs for this example) by typing a password in response to a request from the Web service’s Service project.

The three default claims and their rules appear as shown in this Windows Azure Portal screen capture (click images for full-size captures):

Clicking the edit link opens the Edit Rule page shown here:

Notice the + Add button which lets you group multiple input claims to transform to a single output claim. When you click + Add, you can select the UserName claim type, type a required Value and specify the Issuer (accesscontrol.windows.net for this example). If you have multiple input claims for an output claim, you can select Any, a number, or All “of the input claims that must be satisfied to yield the output claim.”

Note: The following instruction in the Federation.sln Web service solution’s Client.Main() method adds Group as a claim type requirement:

behavior.Credentials.FederationViaCardSpace.ClaimTypeRequirements.Add(new ClaimTypeRequirement(http://ipsts.federatedidentity.net/group));

• Specifying a literal ClaimTypeRequirement in client code appears to me to be an example of the “leaky abstraction” anti-pattern. Claim information and rules should be fully contained in the CardSpace file.

---

Recommended Fix:

Instead of instructing users to click the edit link and + Add button, Exercise 1, step 6a instructs users to click the Add Rules button of the Rules page and add a new rule.

Step 6b is: Complete the Rules form with the following information:

The Input Claim(s) section defines the case of the required claim:

• Type: Group
• Value: Domain Users
• Issuer: FederatedIdentityNet

The Output Claim section defines the shape of the claim to emit:

• Type: Action
• Value: Send

Following these two steps adds an independent Group = Domain Users rule, rather than adding the Group = Domain Users input claim to the existing UserName = oakleaf-acs from accesscontrol.windows.net input claim.

The way I read the tea leaves, instead of clicking the Add Rule button, these steps should instruct users to:

6a. Click the +Add button for the Send action rule.

6b. Complete the Rules form with the following information:

The Input Claim(s) section defines the case of the required claim:

• Type: Group
• Value: Domain Users
• Issuer: FederatedIdentityNet

6c. Change Any to All in the list below the + Add button.

as shown in the following capture:

It might also be wise to add the Group = Domain Users or, perhaps, Domain Admins claim to the Manage Action rule.

---

Additional Issue:

When you preview the CardSpace Information Card from a federated IP-STS, such as FederatedIdentity.net, the preview shows only the Group field to be required. The UserName field is also required by other rules, but doesn’t appear in the preview.

All required fields should appear in the “Card Data That will be Sent to This Site” section.

Setting up Identity Providers (IPs) and configuring CardSpace Information Cards for federated IPs is difficult enough for ordinary users without adding issues like this.

Technorati Tags: Azure Services Training Kit,Windows Azure,Azure Services Platform,Access Control Services,ServiceBus,Workflow,.NET Services,Cloud Computing,Windows Geneva,Geneva Framework,CardSpace Geneva,CardSpace