Authorization Manager Access Component

• Download source files - 186 Kb

Introduction

MSDN published two excellent articles on using Authorization Manager (aka. AzMan) for .NET Authorization ( Keith Brown, David McPherson ), both of which provided deep insight into AzMan Programming. But code samples there, are not directly usable for Application developers, who prefer a simple API to do AzMan Authorization like the following:

    [AzManAuthorizaton("UseCase24", ClaimType = ClaimType.X509)]
    public void MyMethod()
    {
        AzManAccessor.CheckPolicy();
        ....   // the rest of your business logic code
    }

This article demonstrates how to design and code an AzMan Access Component ("AzManAccessor") to achieve this simplicity. Also I have extended MSDN articles on AzMan programming to authorize using WSE 2.0 X509 Certificate and ASP.NET Forms ticket, two very common Web scenarios today.

AzMan Runtime API

AzMan Runtime can be accessed using an interop assembly C:\WINDOWS\Microsoft.NET\AuthMan Microsoft.Interop.Security.AzRoles.Dll in Windows 2003 Server (currently, AzMan is not available for Windows 2000 or XP). This API requires basically two parameters: Operation Name and User Context. In fact, we can build AzMan Client Context by either

      IntPtr h=WindowsIdentity.GetCurrent().Token;
      IAzClientContext ctx= app.InitializeClientContextFromToken((ulong)h,null);

or

      IAzClientContext ctx= app.InitializeClientContextFromName(name,DomainName,null);

where

       name = HttpContext.Current.User.Identity.Name;     // ASP.Net
      // or 
       name = MapSoapContextToUser(RequestSoapContext.Current); //WSE 2.0

and then we can do "Policy Assertion" using AzMan Client Context:

   int oID = GetOperationID(attr.Operation, app);
   object[] reusults = (object[]) ctx.AccessCheck(attr.Operation,null,
                              new object[1] {oID},null,null,null,null,null);
   if ((int) results[0]!=0) { throw new Exception(...);}

where attr is the AzManAuthorization Attribute built using StackFrame Object. Clearly, we have passed all the data needed (operation name and context) through attribute and Context types, a common phenomenon in WS-* message oriented world. While AzMan runtime can now do access right to an operation by a particular user, we have not specified which user has access to which operation yet. This is the job of AzMan Administration MMC Snap-in, which we will take a look next.

AzMan Admin Console

First of all, AzMan Admin model specifies access to an operation through role, not user. In other words, a user will gain access to operation by virtue of being in a role. Secondly, role is defined either by Windows group (just like COM+) or by LDAP query (such as title=Manager), both of which are "queries" under a user context. Now let us take a look at how we build AzMan store in this article:

1. Policy files are in MyStore.xml and can be loaded from Authorization Manager MMC Snap-in.
2. Three operations have been defined (Deposit, Auditing, MarketTiming).

   

   Note that you need to switch to the Developer Mode to see the operation list. This can be done by right clicking "Authorization Manager" node --> Options menu item. Each operation is defined by its name and operation ID.

3. Three roles are defined (Customers, Tellers, Partner).

   

   And we defined each role by adding operation to it.

   

   Specifically, "Deposit" has been added to Tellers, "Auditing" has been added to Partners and "MarketTiming" has been added to Customers.

4. Local "Guest" (disabled) has been assigned to Partners. "Administrators" group has been assigned to Tellers and nothing has been assigned to Customers.

   

   By not adding any user to Customers Role, we stopped any method related to MarketTiming being executed.

Also I assume that you will run demo code "WinTest" as an Administrator and run "WebFormTest" (Form base authentication) as login Administrator/xxxxxx. Otherwise you will need to change Role Assignments in AzMan admin console and change Web config file <authentication><credentials> section to use new group and new user.

Now we have finished setting up AzMan store but we need to install correctly demo code before we can see AzMan at work.

Install Demo .NET solution

System Requirements: Demo code must be run under Windows 2003 Server with VS.NET 2003 and WSE 2.0 installed.

1. Unzip the download file into c:\AzManAccessor.
2. Web Share c:\AzManAccessor as "AzManAccessor" to Default Web Site.
3. Use IIS MMC snap-in to allow "Anonymous Access" to "AzManAccessor". This step is to allow WSTest to run since WSE 2.0 will not flow caller windows context but rather can flow SoapContext. Also in IIS MMS snap-in, Set "WebFormTest" and "WSTest" to WebApplication by right click --> Properties --> create Application name.
4. Run Authorization Manager MMC Snap-in and load c:\AzManAccessor\MyStore.xml and assign "guest" to Partner Role under "Role Assignments Node" and similarly assign "Administrators" group to Telles Role.
5. Click on c:\AzManAccessor\AzManAccessor.reg to update your registry. This will set up Policy URL and default App to support AzManAccessor.

We are done with installation and you should be able to just click .sln to see the demo running.

A note on X509 Certificate

Certificate server need to be installed in Windows 2003 to run this demo. I have included a certificate issued by my server and is definitely not going to work on your server since your certserver or any Cert Authority will not validate it. You should overwrite this certificate using your certserver root certificate. You may also request a trial certificate from VeriSign and install to your certificate store as shown here or even import the test.crt to your own store (Warning: this is a security risk for you since you are trusting certificate issued by me)

Here is the code to load X509 Certificate to WSE 2.0 client.

  X509CertificateStore  store =
             X509CertificateStore.CurrentUserStore X509CertificateStore.CAStore); 

  bool b = store.OpenRead();
  X509Certificate cert = store.Certificates[0];
  store.Close();

  store =X509CertificateStore.LocalMachineStore(X509CertificateStore.MyStore);
  b = store.OpenRead();
  cert = store.Certificates[0];
  store.Close();

Note that I have not tested using VeriSign Certificates in various scenarios such as not connected to Internet or Install to different stores, etc. There are just so many ways to install a public certificate, I can only hope my code can help you to code in some way.

Conclusion

I have presented you a very simple implementation of AzMan Access component. I hope you will find AzManAccessor very helpful in dealing with your real-world problems and share with us your experience.