# Thursday, 15 March 2007

I'm just starting to look into the feasibility of implementing complex constraints in the world of AzMan.  I've already discovered how easy it is to create simple "accessibility" constraints (i.e. can user x execute operation y), but now we need a solution for what we think of as "parameterized" constraints, like can user x execute the transfer operation if the total amount user x wants to transfer is $y.

AzMan certainly provides the capability, in the for of "BizRules", which are scripts that can be attached to roles and other objects to perform exactly this kind of evaluation.  When your application calls CheckAccess, it can pass a set of parameters to evaluate, as well as additional objects, etc.  I have two main concerns about this that I'm going to spend the next week or so evaluating...

  1. Is this going to give us the performance we need?
  2. Is the interface too cumbersome?

Both of those concerns stem from the fact that the only interface currently provided to AzMan is COM based, which means that I'm forced to write my scripts in VBScript of JScript, and I have to pass COM objects (or at least COMVisible objects) for all my parameters at evaluation time.  That means potentially some extra marshalling overhead, although I think there are ways around that.  It also makes the interface to CheckAccess a bit clunky.

I guess I'll find out...

Thursday, 22 March 2007 16:08:22 (Pacific Standard Time, UTC-08:00)
Since I'm about to begin designing a similar authz system, and since I'm pretty familiar with the one you are replacing, I'm really looking forward to your findings. It's nice to have somebody a few steps ahead of me :-).
Jeff Madison
Thursday, 22 March 2007 21:42:37 (Pacific Standard Time, UTC-08:00)
So I started doing some reading on AzMan after seeing your presentation on your current project at the latest CTAB, Patrick. Looks like you're getting to dig into some fun stuff. I've got a few questions/observations, though...

1) In your opinion, why isn't there a managed interface for this thing? I mean, sure, you can follow the Chris Brooks doctrine of "one additional layer of abstraction", but I'm rather stunned that it's not there already.

2) I get why they're using scripts for BizRules - so BizRules can be loosely coupled and easily replaced at runtime. But again, it's like they're determined not to let COM die (passing everything in on AzBizRuleContext). It'd be nice if you could hand off those BizRule decisions to something else, like PowerShell... I suppose you could make a script-based wrapper around whatever else you wanted to drive the decisioning, but it'd probably cost some performance.

3) Regarding your decision to use AzMan on your current project (are we allowed to speak its codename here?), I'm not quite seeing what it brings to the table that System.Security role-based authorization doesn't, except maybe a built-in storage mechanism for roles/permissions (ACLs)... Is that the driving factor in that decision?
Friday, 23 March 2007 08:54:59 (Pacific Standard Time, UTC-08:00)

1) I don't know why there isn't a managed interface. I think it's a stupid choice on MS's part, particularly since more and more of the platform is moving to managed code.
2) If we go with BizRules, we'd actually do all the evaluation in managed code, and just pass the managed interface to the script. Yes, that would incur some performace cost. The choice of script is unfortunate, but that's how it's done in the unmanaged world.
3) On the current project (probably shouldn't speak it's name...) what we get is not only storage, but the fact that AzMan already knows how to deal with ADAM principals, and is very efficient at computing the intersection of a user's group membership with their rights.
Comments are closed.