Here there’s the last episode of the “how-to” series on the ACS Extensions for Umbraco, released (among a ton of other things) at the new ACS’ launch last week.

The feature described here is my favorite: the power of accepting users without having to provision them is one of the most powerful capabilities unlocked by claims-based identity. Making this work on the existing membership-oriented architecture natively supported in Umbraco was an interesting challenge, which IMO deserves to be studied further as it represents a pattern you can apply in many similar situations. Well, in a short I’ll have a long flight to write about it but for now, enjoy the how-to below!

Access Control Service (ACS) Extensions for Umbraco

'Click here for a video walkthrough of this tutorial'

The ACS Extension’s social members integration with the Umbraco member system is, all things considered, pretty simple. It is mostly about single sign on and outsourcing authentication to the supported social providers, which makes things much more convenient for you and your users: but in the end, it is still about provisioning and assigning roles to individual members.

Now, consider for a moment what you could do if the identity provider could tell you more about your members than the simple email address. If for example you’d accept as web site members employees from one business, the identity provider could tell you things like the job they do in their organization, their phone number, the zip code of their office and many other attributes.

One possible use of that information could be to establish authorization policies; for example, you may decide that all members working in Sales for the company X should be assigned to the Power Members role in your Umbraco web site. Being able to express such policies would mean that you would no longer have to manage access control member by member: you���d be able to manage access to all the members coming from a given provider without the need to provision members one by one.

This section will show you how with the ACS Extensions you can achieve exactly that – and very easily -with your Umbraco web site.

Establish authorization policies for Federated Members

The user accounts of business organizations are commonly handled via directory technologies and products, such as Active Directory in the Windows platform. Although those directories are commonly meant to be used within the intranet environment, there are technologies (such as Active Directory Federation Services (ADFS) 2) which enable users in those directory to project their identities and attributes beyond the boundaries of their company network.

ACS can broker authentication between applications and identity providers of every type, social and business. If your ACS namespace is configured to trust one or more of those business identity provider, the ACS Extensions allow you to accept federated members from them. In practice, this means that you can integrate your Umbraco web site with Active Directory and any directory service capable of federation.

In the following tutorial you will learn how to configure ACS to trust a business identity provider, and how to manage access control for its members by defining how the incoming attributes map in Umbraco’s member groups.

1. Navigate to Umbraco back-end and login as the user account you created during the configuration wizard.
2. Go to Members section and scroll the right area until the More about business identity providers pane appears.

   

   Figure 45 - The members section before having configured any business sidentity provider

On the left hand side of the screen, under the Members root you’ll notice a node labeled Business Identity Providers. If the ACS namespace you used for setting up would have contained any relationship with business identity providers, the corresponding entries would have appeared here. On the right pane you’ll notice a warning which states that you have no business identity providers configured yet, and offers you a link to the section of the ACS portal that allows you to add one.

1. Follow the link in the warning; after successful authentication, you will land on the identity providers section of ACS.

   

   Figure 46 - The list of identity providers in the current ACS namespace

As expected, here you see the list of the social identity providers we’ve been using in the first tutorials. Let’s add one business identity provider. Click on the Add link.

1. The UI offers Microsoft Active Directory Federation Services 2.0 as the only business identity provider choice, but in fact any WS-Federation compliant provider should do. Hit Next.

   

   Figure 47 - The first step of the Add Identity Provider flow

   Note:

   If you have an ADFS2.0 instance available, feel free to use it here. For the purposes of this tutorial, we are going to use SelfSTS, one simulation tool which mimics the behavior of a WS-Federation provider for testing purposes. Here we use the SelfSTS instance distributed in the FabrikamShipping SaaS companion, which you can download from here.
   After having extracted the content of the package, launch the SelfSTS instance in C:\FabrikamShippingSaaS_Companion\assets\OAuthSample\AdventureWorks.SelfSTS\SelfSTS.exe and hit the start button.
   

2. The next screen contains all the coordinates that ACS needs to establish a federation relationship with the business identity provider. Fill in AdventureWorks for both the Display name and Login link text fields, then under WS-Federation metadata choose File and paste the path C:\FabrikamShippingSaaS_Companion\assets\OAuthSample\AdventureWorks.SelfSTS\FederationMetadata.xml (assuming you installed the FabrikamShipping companion in the default folder). Finally, hit Save at the bottom of the page.

   

   Figure 48 - The information that ACS requires for establishing trust with a business identity provider

3. AdventureWorks is now listed as one trusted identity provider. The next step is to tell ACS which user information supplied by the identity provider should be made available to applications. To that purpose, click on Rule groups on the left menu

   

   Figure 49 - The list of trusted identity providers now includes AdventureWorks

4. ACS is capable of sophisticated transformation rules, but all we want to do is to make all the user info available: in ACS terms, this means generating a set of pass-through rules for all the attributes (claims) in input form a given provider. Click on the Default Rule Group for Umbraco Relying Party link. You’ll land on a page titled Edit Rule Group, where you can see the existing rules which refer to the social providers. Click Generate to add the ones for AdventureWorks.

   

   Figure 50 - The existing set of ACS rules

5. The Generate Rules page contains the list of configured identity providers: only AdventureWorks is selected, as it is the only one with no rules yet. Click Generate to add to ACS a series of passthrough rules. You’ll be back to the the edit rules group page, and this time you will see the list of new rules (and with them the user attributes that AdventureWorks sends). This concludes the sequence of steps you need to do for ACS to add a new business identity provider.

   

   Figure 51 - The extended rules set now includes AdventureWorks as well

6. At this point you can get back to the Members section in the Umbraco administration portal. Select the Business Identity Providers node, right-click on it and pick Reload Nodes. You will notice that the right pane no longer shows the warning, and that both the pane and the tree now have one entry for AdventureWorks. Expand the associated node in the left tree.

   

   Figure 52 - The Umbraco admin UI reflects the newly added business identity provider

7. You’ll notice that the AdventureWorks node contains a list of all the member groups. Those entries are meant to contain the rules which map an incoming claim into the corresponding Umbraco member group
8. In order to create a new policy rule, select AdventureWorks, right click on Power Members and choose Create: a dialog will appear.
9. Let’s make every salesperson in AdventureWorks a Power Member in your Umbraco instance. In the dialog choose the claim group from the Incoming Claim Type dropbox, and type Sales in the Incoming Claim Value field. Hit create.

   

   Figure 53 - Create mapping rule popup dialog

10. The figure below shows the new rule in the left tree and in the edit pane. That’s all you need to do!

    

    Figure 54 - The new rule mappint AdventureWork’s salespeople to the Power Member s group

11. Let’s test your new settings. Open a new browser and navigate to your content site; here we are assuming that you went through all the steps in the other tutorials and you have the login page set up and the Go further page restricted to Power Members. Click on Go further: as before, you will get to the sign-in page.

    

    Figure 55 - The macro in the Login page automatically reflects the changes in the list of identity providers configured in ACS

The list of identity providers now include AdventureWorks. Make sure that the SelfSTS is running, then hit the AdventureWorks link: you will single sign on and access directly the Go further page, without any need to have a member provisioned. If you want to make a further verification, you can go back to the admin UI and modify the rule by entering clerks instead of sales in the Incoming Claim Value field, hit save and repeat the sequence above: this time the Power Members group is no longer assigned to the AdventureWorks Sales group, hence you will get Unauthorized.

Integrating with business identity providers is a very powerful feature per se: of course nothing prevents you from mixing and matching this with the social member feature.