Mariano Szklanny’s Blog

In my previous post titled "CAB - Adding Command-level security to applications" I implemented a solution that simplifies the common task of enabling/disabling Commands depending on the logged user identity.

Within the download package, I included a sample application that uses Authorization Manager (AzMan) to check authorization on commands depending on user roles. Now I’ll discuss about the design details of this application and how AzMan was used to reach the goal.

Authorization Manager
From MSDN, "Authorization Manager (commonly known as AzMan) is a new general-purpose role-based security architecture for Windows. AzMan is not tied to COM+, so it can be used in any application that needs role-based authorization, including ASP.NET Web apps or Web Services, client-server systems based on .NET Remoting, and so on." [1]

Having said this, let’s see how can we take advantage of the power of AzMaN in combination with the CommandAuthorization implementation.

Setting up AzMan with CAB
The first step that needs to be taken when setting up AzMan is detecting what tasks and low-level operations of an application are considered security sensitive. In this case, I matched these operations directly with CAB Commands. This will allow CommandAuthorization to enable/disable Commands depending on AzMan authorization checking.
The four commands used in the sample application (based on the CAB Commands Quickstart) are:

• ShowCustomer
• DisableShowCustomer
• EnableShowCustomer
• HideShowCustomer

so I created AzMan operations in order to match each one of them:

Picture 1: Each operation in AzMan maps to a CAB Command.

Then, to keep it as simple as possible, I created one task for each single operation:

Picture 2: Tasks map with a single operation.

Finally, I created two roles: Administrator and User. The first one is assigned to the local computer Administrators group and the second one to the Users group.
In picture 3 and 4 you can see the list of tasks that define each role:

Picture 3: Administrator Definition Properties

Picture 4: User Definition Properties

If you want to edit the AzMan store of the sample application, feel free to open the file AzManStore.xml included in the download package under the CommandsQuickstartAzMan folder.

Important: the file AzManStore.xml has to be copied to C:\ before starting the application.

Mapping AzMan Operations with CAB Commands
In the application, I created a service named CommandAuthorizationService that implements ICommandAuthorizationService (the interface required by CommandAuthorization). This service reads available operations and commands from an XML file that follows the schema defined in CommandMap.xsd. In this file, I mapped every single command in the application with an AzMan operation code. For instance, this is the mapping between the ShowCustomer command and the operation op_ShowCustomer:

<Mapping Site="File" Label="Show Customer" CommandName="ShowCustomer" OpCode="1"/>

As you can see, this mapping node also contains information about the extension site the invoker belongs to and the label of the menu item. This is used to create commands and invokers dynamically.
All the information related to commands is stored in a Dictionary (called _commands). When the CommandAuthorizationStrategy builds a work item with the CommandAuthorization attribute, it will ask the service for authorization for every command in the application by calling the method CheckAuthorization. This method looks for the command information in the dictionary and then asks AzMan if current user is authorized to execute it:

Summary
We’ve seen how AzMan can be used to provide command-level security to CAB Applications in combination with the CommandAuthorization solution. My intention with the sample application is to show you a possible scenario where CommandAuthorization can be used. Please, feel free to make any suggestions/comments about this.

[1] More information about Authorization Manager: http://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager/