WCF Security - AzMan [Windows AuthoriZation Manager]

AzMan is the short-form for Windows AuthoriZation Manager. This is one of the option for Role Based Security for enterprise level applications. AzMan provides runtime and GUI tool for managing Role-Based Access Control (RBAC) authorization policies in the form of a MMC Snap-in.

AzMan allows our systems to be divided into various scopes and operations. It allows assigning certain roles mapped to these operations. Now the application just need to determine from AzMan whether the requesting user has permissions to perform the requested operation based on the role assignment to the user. These roles can very easily be mapped to the Windows groups as well but we can also add users directly to these roles. It provides the opportunity to factor out the security logic from the applications and allows to define the authorization policies totally outside the application. It also allows to use scripts [VBScript / JScript] and allows parameter passing for more fine grained security policies. Since the authorization policies has been factored out of the application, it is very easy to assign the responsibility for managing security roles to security administrators. The GUI is based on Microsoft Management Console but it completely supports creating new GUI using the API. The MMC and related runtime libraries are available in %Windir%/System32 folder. You can see in the below image that Azman runtime and GUI are available in Windows 7 out of the box.



The purpose of this post is to see how we can use Authorization Manager to define role based security for our WCF Services. Along the way, we would add the necessary details about using AzMan but it should not be considered as a comprehensive discussion about AzMan.

It has been termed as Microsoft's Best Kept secret. Although this is supported in Windows Server 2012, there are hints that it might be discontinued for future releases. I think this is because of a better tool, Windows Identity Foundation, which I think Microsoft sees as more strategic intra and inter-orgranization role based access control. This is from MSDN:

AzMan is available for use in the following versions of Windows: Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP. It may be altered or unavailable in subsequent versions.

But its use with Active Directory Federation Services [ADFS] provides hope for its continued support. Again from MSDN

AD FS used with Active Directory Lightweight Directory Services (AD LDS) as an identity provider for authentication and Windows Authorization Manager (AzMan) for control of access policy provides a complete solution to extending Web applications to trusted organizations.

AzMan Terminologies

• Operation: Operations are the unit for defining security. They are assigned with a unique numbers which are used by application code. We can only create operations in Developer Mode in AzMan MMC.


• Task: Operations can be grouped together in a task. A task can also be based on other tasks. We can even define VBScript / JScript business rules to be executed with the task. This allows us to defined parameterized rules. We are not using business rules in this example but you can enhance it to restrict the trader for the number of shares which can be traded in a single trade.


• Authorization Store: Authorization store is the storage of these security rules. It can simply be an xml file. Recent AzMan allows SQL Server to be defined as an authorization store. We can even use Active Directory Lightweight Directory Service or ADAM as authorization store.


• Application: An application is a conceptual concept to group scopes and operations. It allows creations of operations, grouping them into tasks, creation of roles and assigning them to these operations and tasks.


• Scope : An application can also be divided into different scopes which can have their own operations, tasks and roles assignment.


• Role: Role is an entity which can be assigned rights on operations / tasks. It is the basis of Role Based Access Control [RBAC]. We can create roles using the AzMan GUI and assign them to Domain Users / Groups. AzMan also supports dynamic roles using business rules where a user can be determined to belong to a role based on this dynamic rule. Like e.g. if a user has a Title as Manager, then he belongs to this role. A role can also be based on other fine-grained roles. These roles are assigned to individual user / groups based on the role assignment supported in AzMan GUI.
  


• Business Rule: Business rules provide dynamic nature to AzMan. Business rules can be used for parameterized operations or roles. AzMan supports business rules in VBScript and JScript. You can define timeout for execution of business rules. They can also be disabled altogether. In that case, if you have business rules defined than the AzMan API cannot be used for permission check.

Supported Repositories
Following repositories are supported to create authorization stores in Azman.

1. XML


2. AD DS: Active Directory Domain Service or ADAM [Active Directory Application Mode]


3. Microsoft SQL Server (new for Windows Vista and Windows Server 2008)

Starting AzMan
As we have discussed, AzMan is a Microsoft Management Console (MMC) based application, we can use it from MMC window. We just need to add a SnapIn to the MMC console and we should be good to go.



Now we can simply add the SnapIn using Add / Remove SnapIn feature of Microsoft Management Console [MMC].



The SnapIn should be available for selection as follows:



Alternatively, we can use the AuthorizationManager SnapIn directly. Just use AzMan.msc from the Run command.



The snapIn should appear as follows:



In the Microsoft Management console window, it should be available under Console Root:



Creating AzMan Authorization Store
In order to create authorization store, we must use AzMan in Developer Mode. We can change the selection by the following dialog available through Action -> Option menu.



Let's use the authorization manager to create an XML based authorization store. Based on the above selection of Developer Mode, we should see the following menu, let's select to create a new authorization store.



Let's make the necessary selection for creation of Xml based store. We need to specify where we want to keep the xml file for the store. We also need to make a selection of the schema. It must be remembered that 2.0 can't be downgraded to version 1.0. Additionally this cannot be accessed by clients using 1.0. But if you are just introducing AzMan in your organization, you should be making the newer schema selection.



Now let's create a new application group by right clicking the Groups folder on the left. The following dialog should appear:



It must be remembered that an application group is a group of users, computers or other security principals. There are three types of application groups: Basic Application Group, LDAP Query Application Group and Business Rule Application Group. These types are based on how the membership would be determined for the group. For an LDAP Query applicaiton group, it is determined dynamically using LDAP [Lightweight Directory Access Protocol] queries. For a Business rule application group, it is also determined dynamically but here it is determined by the scripts written in a scripting language including JScript and VBScript. It can be simpler for a basic application group where it can be determined by windows groups. It also allows to define the membership using LDAP queries.

In order to define Basic application group, let's first create a local group using Computer Management. Let's name it as Traders. At this time, we are not assigning the current windows user to the group.



Now let's use Traders group for our basic application group in Authorization Manager. We have just selected the group using Windows group selection dialog.



As we are updating the security selections, the xml store is being continously updated to include the details. Let's see how it is growing:



If we look at the contents of the store, we can realize how simply the membership is being defined. Here Trader group's SID is being used for the membership.


Creating AzMan Application
All the management of authorization store is done using the same Authorization Manager MMC SnapIn. Just right click the authorization store, you should see the option for creating an application.



Let's create an application for our WCF Service. We are naming the application as TradeExecutionApp.



Authorization Manager applications allow us to define roles, tasks and operations. Yes, they cannot be shared across the applications. This kind of make sense too. An application can have local authorization manager roles as well. The roles can be assigned to Windows / Domain groups or authorization manager groups. For authorization manager roles, the mapping can be defined for local or global authorization manager groups.



Now let's add two operations ExecuteTrade and CancelTrade. The operations should be assigned with a unique operation number. This number would be used when we would be using this policy in an application. An administrator cannot mess with operations because the application is dependent on the operation definitions. Let's create a task and assign the two operations to the newly created task as follows:



We need to assign the tasks and operations to a role to define security privileges. Authorization Manager supports creating roles. Here we are creating a role, named TradeExecutionRole and adding the task created above to the role. The roles can be assigned with operations or tasks. These roles can also be based on other roles. This can be used to define more fine grained security roles and then combine them to create roles for different related features.



These roles can be assigned to a group. Than authorization manager or a Windows / Domain group. Let's assign the role to TradeExecutors global authorization manager group.



As we have been adding these roles, tasks, operations and assignments, Windows Authorization Manager has kept updating the Xml authorization store. Let's see how it has kept the definition updated:

Using AzMan Roles for Securing Applications
This is the area which has very limited information available on the net. First of all, on my Windows 7 Ultimate machine, the folder is empty. The folder can be founded as being recommeded for referencing Microsoft.Interop.Security.AzRoles assembly. To be fair to the recommeders, I don't have a server machine where I am creating this application [http://msdn.microsoft.com/en-us/library/aa480244.aspx]



I can find the assembly can be found in the Global assembly cache.



To be exact, the Microsoft.Interop.Security.AzRoles assembly can be found in GAC_32 folder in global assembly cache.



We can browse to the GAC to add this assembly in our project.



This is actually an interop assembly for AzRolesLib.dll. We can also add the direct reference of AzRolesLib using Type Library. This would create an interop assembly in obj\Debug folder. Here we have added the reference of the library in a sample project.



Let's use AzMan based Role Based Access Control in our WCF application TradeExecutionServiceLib. Let's create a managed wrapper around the AzMan runtime libraries access as follows:



Let's create an enumeration for the operations for the application. This would help us avoiding to use the operation numbers spread across the entire code base. It must be remembered that AzMan Admin MMC doesn't allow to create / modify the operations in the Administrator mode. If we need more operations then we need to develop for implementing those operations in our applications, hence developer mode for AzMan MMC. You can see that here we have used the same operation numbers as we defined in AzMan for creation of these operations.

Now let's define an interface for checking the access on an operation for an identity. This would allow us to change the RBAC move to a different store than Windows Authorization Manager.

Now let's provide AzMan based implementation of the above interface. The type has a constructor where it requires the connection string and application name. It also has a method to implement the method checking the access rights of an IIdentity on an Operation.

Now since we have policy definition and required code completed now, we can use it in our Trade Execution Service. You can get the code from our previous post and add the above code as an existing project to the solution. You would need to add an assembly reference into our service project. It would also be required to get rid of custom Service Authorization Manager from code and App.Config.

AzMan and Enterprise Library 5
Enterprise Library - Security Application Block allows defining authorization providers. The authorization provider allows introducing security as an orthogonal pluggable concept. AuthorizationProvider.Authorize takes an IPrincipal and operation name as an input. This is similar to the requirement of AzMan. You can read further about how we can use AzMan with Security Application Block in Enterprise Library 5.0. You can even use the AzMan managed wrapper created here and use it with the Authorization Provider.

http://msdn.microsoft.com/en-us/library/ff664559(v=pandp.50).aspx

You can also find a few nuget packages provided by Microsoft and other community members in order to provide ease of development using AzMan. You can specially look at the security provider package for Enterprise Library 5.0.



Further Reading / Reference?

• Developing Federation aware applications { Windows Server 2008 } - Windows Authorization Manager:
  http://msdn.microsoft.com/en-us/library/bb897401.aspx


• Donovan Follette has a series of videos on Channel 9 discussing about AzMan:
  http://channel9.msdn.com/Blogs/donovanf/Demystified-Series-Getting-Started-with-AzMan
  

Download Code