# Wednesday, April 04, 2007

Since there's not way to manage an explicit "Deny" in AzMan like there is with ACL's, that has some influence on the way in which we will have to define roles.  Let's say I have a group hierarchy like this...

  • Ray's Bakery
    • Admins
    • Bill Payers
    • Corporate Headquarters
      • Finance
      • Payroll

If we have the ability to deny, we might give rights to all operations to the top level "Ray's Bakery", and then deny rights to "Payroll" for example that we don't want that group to have, but are OK for "Finance".  It's relatively easy to understand, and has the advantage of being not very much work. 

Because of the way AzMan works, however, we have to work from the top of the hierarchy down, going from most restrictive to least restrictive.  In other words, we can only assign rights to the "Ray's Bakery" group that we want ALL users to have, then grant additional rights as we go down the tree.  We might want everyone in Finance and Payroll to be able to see balances, so those rights could be assigned at the "Corporate HQ" level, while rights to transfer money from one corporate account to another might be granted only to Finance, and rights to wire transfers only to Payroll.  This should also be pretty easy to understand, but it does require a bit more thinking about.  I think a good test tool will help make it clear to users who has what rights, so it shouldn't be too hard to follow. 

For the sake of clearing up any implementation details, what I'm really describing are hierarchical groups in ADAM, which are associated with AzMan roles, so when I say "assign rights at the Finance level", I mean that the group SID for the Finance group in ADAM will be associated with an AzMan role called something like RaysBakeryFinance, which is in turn associated with the operations or tasks that comprise wire transfers. 

Wednesday, April 04, 2007 4:01:29 PM (Pacific Daylight Time, UTC-07:00)
I'm afraid I don't completely understand, Patrick. Even though AzMan doesn't have a construct for "deny," does that prevent you from creating your own?

In other words, I'm assuming that right now your access check for a given operation looks kind of like this (greatly simplified pseudocode):

if (ManagedAzManWrapper.AccessCheck(UserIdentity, "SomeOperation"))

Why couldn't there be two roles defined instead? So you instead you would do:

if (ManagedAzManWrapper.AccessCheck(UserIdentity, "SomeOperation") && !(ManagedAzManWrapper.AccessCheck(UserIdentity, "DenySomeOperation"))

So AzMan doesn't know you want to deny a user the ability to execute an operation; The application just leverages AzMan to see if a given user belongs to one or both of two different roles.

Wouldn't this give you the "deny" behavior you want?
Wednesday, April 04, 2007 4:48:34 PM (Pacific Daylight Time, UTC-07:00)
Hmm. I hadn't considered that approach. That would mean I'd be adding additional semantics at the level of my application that AzMan wouldn't really know about. And I'd have to hide those additional roles in the admin tool. I think I'd want to model it as a functional deny in the tool, and use the additional role internally.
Definitely something to consider, thanks!
Wednesday, April 04, 2007 5:04:21 PM (Pacific Daylight Time, UTC-07:00)
Glad I could be of service. We don't get too many of these fun types of problems in a bank. :)

If you end up using something like this, all I ask is some props on the blog. :)
Comments are closed.