Matias Woloski’s Blog

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

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.

This week I did an architecture review together with German Marin, from Microsoft Consulting Services Chile for an MS partner, Novared, who is willing to implement a large application including Biztalk in the Middleware to conceive a unique customer database. Novared wanted to make the decision whether to use or not MBI 3 as the business framework in cooperation with Biztalk.

Happily, after one week implementing a proof of concept they decided that MBI will be the framework they will use from now on for their applications. Indeed, they realized that using it, will lead to:

• shorter development time;
  
• better support; 
  
• improvement on the development team workload distribution;
  
• enhaced quality on the solution;
  
• opportunity to create a base framework and have isolated development teams that implement the business actions
  
• and some other benefits.

The proof of concept included among other things:

• Single and Batch actions;
  
• Command Pattern & Service Oriented approach; 
  
• Request-Response sync communication with Biztalk 2004 orchestations;
  
• Business Event publishing using Output Providers;
  
• use of the MSMQ transport to inject data to Biztalk; 
  
• discussion of BAM (Business Activity Monitoring) in conjuction with MBI;
  
• Authorization Manager (AzMan) integration within MBI;
  
• Extensibility and Flexibility of the pipe & filters pattern;    

I’m leaving Chile with a lot of ideas spinning on my head. Specially regards EDRA / MBI 3 / Biztalk Server 2004 integration. I splashed the first ideas on under: EDRABiztalkIntegration