Tuesday, April 17, 2007
Implementing denials in AzMan

I've been wrestling for a while with how to deal with the fact that AzMan doesn't natively have a concept of denials.  I'd convinced myself that you could structure a hierarchy of grants such that you wouldn't really need an explicit denial, but I got a use case last week that proved that it really is necessary (without doing something REALLY horrible). 
I started with some suggesting from Cam, and modified it a bit into something that I think will work going forward.
The basic idea is that for every operation we want to add grants for, e.g. "GetAccounts", we also add a hidden operation called "!GetAccounts".  To keep them separated, we also offset their AzMan operation IDs by some arbitrary constant, say 100,000.  They when we do access checks, we actually have to call IAzClientContext.AccessCheck twice, once for the grant operations and once for the deny operations.  The results get evaluated such that we only grant access for an operation if the access check succeeds for the "grant" operation, AND doesn't succeed for the "deny" operation. 
 
WindowsIdentity identity = WindowsIdentity.GetCurrent();
 
IAzClientContext client = app.InitializeClientContextFromToken((ulong)identity.Token.ToInt64(), null);
object[] scopes = new object[] { (object)"" };
 
object[] grantOps = new object[] { (object)1, (object)2, (object)3, (object)4};
object[] denyOps = new object[] { (object)100001, (object)100002, 
     (object)100003, (object)100004 };
 
 
object[] grantResults = (object[])client.AccessCheck("check for grant", 
     scopes, grantOps, null, null, null, null, null);
object[] denyResults = (object[])client.AccessCheck("check for deny", 
     scopes, denyOps, null, null, null, null, null);
 
for (int i = 0; i < grantResults.Length; i++)
{
       if(((int)grantResults[i] == 0) && ((int)denyResults[i] != 0))
            Console.WriteLine("Grant");
       else
            Console.WriteLine("Deny");
}

We'll hide all the details in the administration tool, so that all the user will see is radio buttons for Grant and Deny for each operations.

I'm pretty happy with this for a number of reasons

  • it gives us the functionality we need
  • it's easy to understand (no coder should have a hard time figuring out what "!GetAccounts" means)
  • all of the logic is localized into the admin tool and the CheckAccess method, so the interface to the client doesn't change
  • it's not too much additional semantics layered on top of AzMan, and we take full advantage of AzMan's performance this way
 |  | 
Tuesday, April 17, 2007 10:44:12 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  |  Related posts:
A new role
Configuring AD-LDS
Continuous Integration at SAO
Continuous Integration at SPIN
Code Leader is shipping
Firebug
Wednesday, April 18, 2007 11:26:23 PM (Pacific Daylight Time, UTC-07:00)
I am so stoked that I made a suggestion that eventually led to your solution! :)
Cam Soper
Saturday, April 21, 2007 1:11:45 AM (Pacific Daylight Time, UTC-07:00)
Good idea. Looks like you're in the thick of architecting an AzMan solution as well. Are you using the scopes property for resource entitlement? What does your administration interface look like - or are you using the mmc snap-in? Seeing as how the AzMan community is currently small, I'd be interesting in trading e-mails on the way it works out.
Robert Baumann
Monday, April 23, 2007 5:07:15 PM (Pacific Daylight Time, UTC-07:00)
Robert,

we aren't currently using scopes, but that may change. We are not going to be using the MMC snap-in, since right now it doesn't work with ADAM principals. That support is coming in Longhorn, but we can't wait, so we'll be writing our own admin tool.
Patrick
Comments are closed.