# Monday, 26 March 2007

A very common banking scenario is one in which Customer Service Reps (CSRs) need to act on behalf of a given user to help them through problems.  This usually occurs when a customer calls a bank, and the CSR needs to essentially log into the online banking system "as" that customer, but without knowing that user's password. 

Once they are logged in, there are some things you'd like them NOT to be able to do, like create a new bill payment payee and send bill payments to it.  'Cause that's bad.

I'm trying to figure out how that would be modeled in AzMan, since as near as I can figure there's not such thing as an explicit "deny" in AzMan.  All rights are essentially additive, and if any of a user's roles includes a grant, access is granted.  At least that's the way it seems to behave, I could be wrong. 

In a perfect world, we'd like to be able to simply model "the CSR can do everything the user can, except...". 

The only way I can figure to make this work in AzMan right now is to create the CSR role with access to all operations except those on the deny list, then when the CSR logs in, do restrict the AccessCheck against AzMan to only the CSR role, by setting the IAzClientContext's RoleForAccessCheck property.  That way, only the CSR's rights are evaluated, even if they are assigned to other roles as well. 

Not ideal, but at least it's easy to understand...

Monday, 26 March 2007 14:40:32 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Thursday, 15 March 2007

Donovan Follette, ADAM/AzMan/Identity Evangelist at Microsoft, has posted a set of links to some videos, whitepapers, and case studies on using AzMan.  Not only are these great resources, but it's great to see Donovan working to make sure that AzMan doesn't stay the "best kept secret" in Windows 2003 Server. 

One of the big questions we've had around using AzMan has been "is anyone actually using this thing?", so it's very cool to get our hands on some real case studies to answer that question in the affirmative.

Thanks Donovan!

Thursday, 15 March 2007 13:57:36 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

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, 15 March 2007 13:21:44 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [3]  | 
# Wednesday, 07 March 2007

This is mostly an annoyance, but I've noticed that every time I try to attach the VisualStudio 2005 debugger to the w3wp.exe process (to debug a WCF service hosted in IIS, on Windows 2003 Server), the Attach to Process dialog automatically tries to debug Workflow and T-SQL code, not managed code.  This then causes VS.NET to crash instead of attaching the debugger. 

When I remember to set it manually to Managed instead, everything works just fine.  The drag is that there doesn't seem to be an obvious way to turn off the automatic selection.  Every time I start this process, I forget, crash the app, then remember to select manually.  Costs some extra time I'd rather not spend.

I suppose on the other hand, I could just pay more attention.

Wednesday, 07 March 2007 10:58:26 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

It's highly encouraging to me that MS is continuing investment in ADAM.  There have been a number of naming changes for "Longhorn" Server, and ADAM hasn't escaped.  The new name is ADLDS, for Active Directory Lightweight Directory Services.  A much more appropriate name, since it says exactly what ADAM does.  It's the LDAP part, without the NOS bits of AD. 

I've noticed that the name change even shows up in a few places on the Windows 2003 Server site, which is a bit confusing.

Anyway, the take away is that not only is ADAM not going away, but it's a part of the platform that MS is committed to not only supporting but improving.  Does my heart good.

Wednesday, 07 March 2007 10:29:34 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |