Authorization Manager (AzMan) handler for EDRA and MBI 3.0

Recently, I had to get deep on AzMan for a project. This tool helps you to manage operation and roles for a custom application. It runs on Windows 2000, Windows 2003 and Windows XP which developers generally use. Just install the Windows Server 2003 Administration Tools Pack and you'll get an MMC snap in like this


azman


In a nutshell, AzMan allows you define Roles, Tasks and Operations. Operation is the atomic unit of AzMan. In terms of EDRA or MBI an operation will map to a Business Action. This way we can group operations in a task. For example, the system actions in MBI could be grouped all together in a task System Actions, and then we can define a role that has access to that task.


Task could nest task or operations and roles could nest roles, task and operations. This gives you a lot of flexibility to manage authorization for your app.


Now, the issue is how we can integrate this beatiful UI with our services. AzMan has a COM api available via Interop to .Net, that exposes the whole functionality. We are intereseted in one method specially which is the AccessCheck. This method will check authorization of a user against an operation


result = context.AccessCheck( "operation" )


In terms of EDRA or MBI, we need to grant or revoke access to services or actions. We have the concept of pipelines and filters (handlers) which give us lot of flexibilty and extensibility. What we should do is create a handler and put it in the interface pipeline (in MBI there is a single action pipeline, so we should replace the common Authorization handler with this one). The handler will do the AccessCheck and it will throw an exception wheter the user has access or not to execute a given service action.


The type of the EDRA handler will be an Atomic one, because we just need to intercept on the request in the interface, cutting any bad request from the ground. Here is the code for the Execute method of the handler (the MBI version)


public void Execute(IContext context)
{
    Command cmd = ContextHelper.GetCommand( context );
    bool authorize = true;
    IAzApplication azApp = null;
    IAzClientContext azContext = null;

    foreach( string excludedAction in _config.ExcludedActions )
    {
        if ( excludedAction == cmd.Action )
            return;
    }

    string userName = Thread.CurrentPrincipal.Identity.Name;
    // check user exists for the application
    try
    {
         azContext = GetClientContextFromName( userName, _config.ApplicationName, out azApp );
    }
    catch
    {
        authorize = false;
    }

    // now check roles
    if ( authorize )
    {
        // check user is authorized to execute the action
        authorize = AzManHelper.CheckAccess( cmd.Action, userName, azContext, azApp );
    }

    if( !authorize )
    {
        throw new TechException( Resource.ResourceManager[ Resource.MessageKey.NotAuthorized, cmd.Action, userName ] );
    }
}


For an EDRA version you should change cmd.Action for context.ServiceActionName and throw a BusinessRuleException instead of a TechException.


I wrote an AzManHelper which helped abstract and encapsulate the AzMan api. I think the code is straightforward in terms of simplicity. We are doing this:



  1. IF the action being executed is excluded from configuration, just return to the pipeline. This is for actions that we want to bypass the access check.
  2. Get the username from the current principal
  3. Get the client context of AzMan for a given user and a given application (the application is the same that you created in the AzMan UI). If there was any problem getting the context set the flag to false
  4. If the context was obtained, try the AccessCheck for the executing action, username and context
  5. If it couldn't be authorized throw an exception

You can find the full source code for the handler: AzManHandler.zip (6.77 KB)


Thanks to Federico Winkel who helped a lot on this.

Published: January 19 2005

blog comments powered by Disqus