Confused about the realtionship between the different item types

May 28, 2009 at 3:48 PM

Hello again,

 

 

I thought I understood the semantics of the hierarchy but when playing around w/ the MMC Snap-in console and using the built in 'Check Access Test' the results confused me.  Let me describe my hierarchy, the authorizations I assigned and highlight expected results vs. actual results.  

 

Application_A

<Item Definitions>

<Roke Definitions>

Role_1 (has task_1, task_3, operation 1)

Role_2 (has task_2, operation_1)

<Task Definitions>

Task_1 (has operation_2, operation_3)

Task_2 (has operation_2, operation_3)

<Operation Definitions>

Operation_1

Operation_2

Operation_3

 

 

 

Authorizations Check Scenario 1:

<Item Authorizations>

<Role Authorizations>

Role_1 - User_A is Allowed

Role_2 - User_A is Denied

 

 

When Running 'Check Access Test' for User_A I got the following results:

Role_1 - Allowed (expected Allowed)

Task_1 - Allowed (expected Allowed)

Operation_2 - Denied (expected Allowed)

Operation_3 - Denied (expected Allowed)

Task_2 - Denied (expected Denied)

Operation_2 - Denied (expected Denied)

Operation_3 - Denied (expected Denied)

Operation_1 - Denied (expected Neutral)

 

 

 

Authorizations Check Scenario 2:

<Item Authorizations>

<Role Authorizations>

Role_1 - User_A is Allowed

Role_2 - User_A is Allowed

<Task Authorizations>

Task_1 - User_A is Allowed

Task_2 - User_A is Denied

 

 

When Running 'Check Access Test' for User_A I got the following results:

Role_1 - Allowed (expected Allowed)

Task_1 - Allowed (expected Allowed)

Operation_2 - Denied (expected Allowed)

Operation_3 - Denied (expected Allowed)

Task_2 - Denied (expected Denied)

 

Operation_2 - Denied (expected Denied)

Operation_3 - Denied (expected Denied)

Operation_1 - Allowed (expected Allowed)

 

 

It appears that permission checks perform 'bit wise' AND operations across each level in the hierarchy, applying the most restrictive authorization; not what I would have expected.  Being what it is, how would you suggest I organize my permissions to get the desired affect.  Real world example:

 

I've got two forms (Form_1 and Form_2), both with two corresponding permissions (Modify, Read Only).  I want to assign user_a with read_only rights on form_1 but have full rights on form_2.  Right now it seems the only way to make this happen is to treat the form as an application rather then a role or a task.

 

 

Do I have this correct?

 

 

Thanks,

 

Dave

 

May 28, 2009 at 8:35 PM
Edited May 28, 2009 at 9:20 PM

Hi Dave,

 

deemed this comparison:

- Roles  are like Folders

- Tasks are like subfolders

- Operations are the files.

 

If User_A has Deny on the root Folder …  he never could read files inside root folder and subfolders.

If User_A has Allow on roof Folder … permissions depends on subfolders … and so on.

 

When you say:

“I've got two forms (Form_1 and Form_2), both with two corresponding permissions (Modify, Read Only).  I want to assign user_a with read_only rights on form_1 but have full rights on form_2.  Right now it seems the only way to make this happen is to treat the form as an application rather then a role or a task.” … you are implicitly admitting the Read_only on form1 must be a “different operations” of Read_Only on form_2.

 

What I suggest is …

1) Don’t think in terms of “generic” operations … on all forms … but think in terms of  “specific” operations for each form;
i.e.: “read on form1”, “write on form1”, “read on form2”, “write on form2” (are all operations) and so on (they are really different operations that can be assigned to different Roles (Users))

2) Tasks are operation aggregators (Use a Task to group several operations, then just assign a task to a Role – this is more quickly instead of assign several operations to a Role)

3) Users in the same Role can performs the same “operations”
i.e. “Managers” Role with all read/write operations (for each forms)

 

Regards,

Andrea.

May 28, 2009 at 9:01 PM

First, I REALLY appreciate the rapid feedback and the time you've put into this project.  It's really appreciated.

 

Regarding your response....my expectations were based on the folder/sub-folder/file metaphore.  However, the key difference is that file systems are trees where the models we can build using NetSQLAzMan could resemble DAGs.  So what I observed (and caused the confusion) was that if a user was associated w/ multiple roles for example but w/ different permissions, the permission of the operation (file) was set to be the most restrictive if there were multiple paths to it.  This is also true of tasks (sub-folders).  

 

Anyway, I think I understand how it's organized and have re-worked how model of authorizations should map onto NetSQLAzMan's hierarchy.

 


Once again, thank you.

 

Dave

May 28, 2009 at 9:03 PM

If I need help to build the Hierarchy … just ask.

The NetSqlAzMan community (and me) … are here J