"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 is deprecated as of Windows Server 2012 R2 and may be removed in subsequent versions."
"AzMan is a role-based access control (RBAC) framework that provides an administrative tool to manage authorisation policy and a run time that allows applications to perform access checks against that policy. The AzMan administration tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in.
Authorisation policy is managed separately from an application’s code. The application designer defines the set of low-level operations that are considered security sensitive and then defines a set of tasks that map onto those operations. The tasks, but not the operations, are designed to be understandable by administrators and business analysts."
Windows Server 2003 was way before the era of claims-based authentication and no doubt it had a place then.
Imagine a library. There could be two kinds of people; librarians and users.
Users can browse the catalogue and check in / out books. Librarians can also do those functions plus they can order books. So the list of tasks could be:
Now the steps in ordering a book could be:
So the librarian would first check that there was enough budget, then check that the supplier has stock and then process the order.
There is a hierarchy of Role which has Tasks which has Operations. Each operation has a number.
Now you assign Tasks to Roles and then Operations to Tasks.
Lastly, you then assign users to Roles under "Role Assignments" above.
This is all wrapped up in an Application. As above, in the tree, "Library" is an instance of an application.
You then used .COM objects to get the assignments and you ended up with an array of ints; each element was a binary for the operation of that number e.g. if "Check budget" was numbered one, then the first instance in the array would tell you if the user had permission to perform that operation.
Never having used Azman, I may have some details wrong but they are close enough to illustrate the point.
This is all well and good but how to you migrate this to a modern claims-based world using e.g. ADFS.
ADFS authenticates against Active Directory (AD) and AD does not directly support the above structure.
AD does not have a concept of "application" and I'm ignoring that for the moment as my particular requirement was to migrate an Azman based program that only had one application.
AD does allow a hierarchy of roles (called Groups in AD) e.g. A can be memberOf B can be memberOf C.
The problem is that the groups do not display in a hierarchical manner e.g.
The way this is setup in AD is that:
"Librarian" is a memberOf "Order book" is a memberOf "Check budget".
The user is then a memberOf "Librarian".
In terms of setting up the claims-based application, there are two ways to go:
- WIF (the older way but still supported)
- OWIN WS-Fed (the newer way)
How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF
where the STS = ADFS.
For OWIN, there is a Azure AD sample:
Integrating a web app with Azure AD using WS-Federation
and then convert to ADFS by using:
Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS.
On the ADFS side, be sure to add an LDAP rule that maps "Token-Groups - Unqualified Names" to "Role".
Using this and by adding the code in the gist to display the claims, my user that has the Librarian Role displays as:
The code can now use the IsInRole construct.
Refer Working with claims-based identities in multi-tenant applications for other ways to look at the claims.
Hopefully, this provides enough of the plumbing to get you across the line during your Azman migration.