# Monday, March 26, 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...

Tuesday, March 27, 2007 12:27:07 PM (Pacific Standard Time, UTC-08:00)
It sounds like you may have to get more granular on your operations. How about creating all of the operations that a user and a CSR can do, then add only the appropriate operations to AzMan role definition.
Friday, March 30, 2007 9:24:31 AM (Pacific Standard Time, UTC-08:00)
I think that's what Patrick's saying he's planning on doing - And that the CSR role definition will be used to the exclusion of any other roles.

Wow, it seems weird that there's no "deny."

Patrick, are you saying that permissions are neither "allow" nor "deny" in AzMan - They're just a boolean construct? In other words, roles and permissions are less like NTFS file security and more like SQL Server?

Take, for example, SQL Server - It defines, at the table level, permissions for each action on each object: User Foo is granted SELECT and INSERT on table Bar, but he is not granted UPDATE or DELETE. User Foo might be a member of the either the DataReader or DenyDataReader role at the database level, though - and that brings a long with it a default set of permissions.

Am I close?
Comments are closed.