This was going to be a single post, but it got too long – so this first part
introduces Authorization Manager and describes how to get it setup, and the
second part will discuss how to apply this technology in the ArcGIS
environment.

Authorization Manager
Also known as AzMan, this is a
component of Windows Server 2003 which provides a “role-based” security store
along with a developer API that you can work against. At it’s core, AzMan works
with “Operations” to which access is granted or revoked based on role
membership. In addition to working directly with roles and groups on the local
machine or in Active Directory, AzMan can also manage it’s own roles and groups.
This is very convenient if IT policy does not allow you to have application
specific roles & groups in Active Directory itself. Although the AzMan API
(azroles.dll) is installed on XP by default, you need to download the Windows
Server 2003 admin kit to get the managment console snap-in. If you are
running in Vista or Windows Server 2003, this is already installed.

How it works (30,000 foot view)

The application uses AzMan to ask if a user has access to a particular
Operation. AzMan looks at the users group & role membership and determines
if they have access. Simple & clean.

This is very nice in that it provides a layer of indirection between your
application code and the authorization system. As long as the authorization
system knows about the operations you application is going to request, it does
not matter how the users are granted access (via Active Directory roles &
groups, via AzMan roles & groups, or via individual users). This is much
preferable to writing an application which depends on specific roles &
groups to exist in Active Directory.

Using AzMan

Before we start building an application, we need to setup an AzMan repository
that we can use to control access to our functions. For this example we are
using an Xml file to store the repository but it’s also worth noting that you
can store it in Active Directory. Again, I highly recommend Keith Brown’s screen
casts for the details. At a high-level, these are the steps:

1) Open the AzMan MMC (Start –> Run –> azman.msc

2) Change to developer mode

3) Create a new repository (xml file)

4) Create an Application
(”ExampleApp”) and add operations

 

6) Create roles (Managers) & assign operations to the roles

7) Grant users (local or Active Directory) access to the operation

AzMan API

Now that we have our (basic) repository, we area ready to use AzMan to secure
our code, and we do this via the API. The AzMan API is a set of COM
classes located in AZROLES.dll. And while we can access this library directly, I
would recommend creating a utility class that hides a lot of the details. In the
next posting, I will include an “AzManHelper” class (derived from a C# class from
Keith Brown ) in the sample code which does just this. Basically it just exposes
a “CheckAccess” method which returns a boolean. For now, I recommend taking a
look at Keith’s screen casts on Channel9, and checking out his sample code
(links below)

Up Next…
In the next posting I’ll cover how you can use
this to add role based security into your ArcGIS applications and provide some sample code.

Keith Brown’s Channel9 Screencasts:
Getting Started with
AzMan
Programming
AzMan Code
Sample
AzMan in the
Enterprise  Code Sample

This was pretty weird, and thankfully others on my team had already run into it, so it was a quick fix. Thought I’d share it…

Here’s the basic scenario:

We have some base classes which contain a lot of common code for feature and object class extensions. The ObjectClassExtensionBase class implements IClassExtension

This is a very simple Interface – it has two methods Init and Shutdown. All is well, and we’ve been building this project for a couple of months. This morning I created a new project, in which I referenced the assembly containing the base classes.

 

Suddenly I start getting 2 compile errors in the “Base” class assembly:

How’s this for wack – the first error says that I need to implement Sub Init for IClassExtension, and the second error says that my Sub Init can not implement IClassExtension.Init because it’s not present in IClassExtension??! They contradict each other!

After some head scratching I asked around, and others have run into this recently. Seems that the issue is related to some referenced ESRI .NET assemblies being located in the GAC. What’s even more bizzare is that the error can crop up in a different assembly than the one that has the offending reference.

In my situation, our “BaseClass” assembly had not changed. Yet that’s where the compile error showed up. I checked all the ESRI references in that assembly, and they were all pointing to the expected “C:\Program Files\ArcGIS\DotNet\something.dll”.

However, when I looked at the references in my “new” project, the ESRI.ArcGIS.System assembly it was referening was located in the GAC…

Conveniently I did not actually need this reference, and as soon as I dropped it, everything compiled just fine.

Interestingly – if I add this reference via the standard Visual Studio “Add Reference…” dialog, it uses a copy that’s in “C:\Program Files\ArcGIS\DotNet”

But, if I add it via the ESRI ArcGIS Reference add-in, it adds a copy from the GAC and the error returns.

As for why this is an issue, I’m guessing it’s an all or nothing type of thing – either all the ESRI references should come from the GAC, or all from C:\Program Files\ArcGIS\DotNet, and a mix will cause problems.

Anyhow – hope this is useful to someone else.

This is a temporary post that was not deleted. Please delete this manually. (68744e6f-567c-4783-9a03-3d7102f6fab8)

Chicago Yesterday, originally uploaded by Dave Bouwman.

Some burly weather around Chicago yesterday. Grabbed this shot of the weather radar after we diverted to Des Moines for more fuel.