Thoughts on Authorization in a Hierarchical User Structure.
-
I am busy developing a timesheet capture service which has a hierarchical user structure[1], where e.g. the top user in a hierarchy represents a distinct organization or related group of users. This user can then create more users under their self. This design has been laid down by my client. For authorization, I have interpreted this so that a user higher up in the user tree has access to all users below them in the tree, as well as entities owned by those lower users. This seems logical to me, as a user higher in the tree 'owns' users lower down. The client is not clear on whether this is the way to go, as in some situations it is ideal that users lower down have access to entities created by users above them in the tree. My client is unclear on what he wants here and expects some assistance in deriving a practical authorization scheme for this hierarchical user scheme. Let me introduce the entity Customer to this scenario. Originally, a User owned Customers, so in my interpretation, a user higher up in the tree (more senior) had access to all customers owned by users lower down in the tree. This preserves the higher privilege of higher users, but prevents a more senior user creating customers for more junior users to work on. Now I have to change this one user to many customers relationship to many users to many customers, complicating things somewhat. I'm not asking for a solution here, but some input and maybe suggestions or warnings for proceeding to try and devise a working authorization scheme for this complex matrix of user trees crossed with customer trees. [1] Many other entities are also hierarchical, but not yet relevant here.
-
I am busy developing a timesheet capture service which has a hierarchical user structure[1], where e.g. the top user in a hierarchy represents a distinct organization or related group of users. This user can then create more users under their self. This design has been laid down by my client. For authorization, I have interpreted this so that a user higher up in the user tree has access to all users below them in the tree, as well as entities owned by those lower users. This seems logical to me, as a user higher in the tree 'owns' users lower down. The client is not clear on whether this is the way to go, as in some situations it is ideal that users lower down have access to entities created by users above them in the tree. My client is unclear on what he wants here and expects some assistance in deriving a practical authorization scheme for this hierarchical user scheme. Let me introduce the entity Customer to this scenario. Originally, a User owned Customers, so in my interpretation, a user higher up in the tree (more senior) had access to all customers owned by users lower down in the tree. This preserves the higher privilege of higher users, but prevents a more senior user creating customers for more junior users to work on. Now I have to change this one user to many customers relationship to many users to many customers, complicating things somewhat. I'm not asking for a solution here, but some input and maybe suggestions or warnings for proceeding to try and devise a working authorization scheme for this complex matrix of user trees crossed with customer trees. [1] Many other entities are also hierarchical, but not yet relevant here.
Brady Kelly wrote:
For authorization, I have interpreted this so that a user higher up in the user tree has access to all users below them in the tree, as well as entities owned by those lower users. This seems logical to me, as a user higher in the tree 'owns' users lower down.
I don't find that logical. If I were a node in your tree, I'd only pay attention to my parent - the topnode would never be relevant in my work. That's based on the idea of a "chain of command". If my bosses' boss could manage me directly, my boss would be superfluous. Better to check with the client whether your interpretation is correct.
Brady Kelly wrote:
My client is unclear on what he wants here and expects some assistance in deriving a practical authorization scheme for this hierarchical user scheme.
"Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Brady Kelly wrote:
This preserves the higher privilege of higher users, but prevents a more senior user creating customers for more junior users to work on.
Not per se; just make sure that the junior is "part of" the group working on the customer :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
Brady Kelly wrote:
For authorization, I have interpreted this so that a user higher up in the user tree has access to all users below them in the tree, as well as entities owned by those lower users. This seems logical to me, as a user higher in the tree 'owns' users lower down.
I don't find that logical. If I were a node in your tree, I'd only pay attention to my parent - the topnode would never be relevant in my work. That's based on the idea of a "chain of command". If my bosses' boss could manage me directly, my boss would be superfluous. Better to check with the client whether your interpretation is correct.
Brady Kelly wrote:
My client is unclear on what he wants here and expects some assistance in deriving a practical authorization scheme for this hierarchical user scheme.
"Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Brady Kelly wrote:
This preserves the higher privilege of higher users, but prevents a more senior user creating customers for more junior users to work on.
Not per se; just make sure that the junior is "part of" the group working on the customer :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Thanks, I'm slowly discarding big parts of my original concept, and moving toward the tree just representing the org, and everyone in the org (in the tree) having access to everything else in the tree, but limited by user roles.
Eddy Vluggen wrote:
"Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Authorization doesn't involve logins, Authentication does.
-
Thanks, I'm slowly discarding big parts of my original concept, and moving toward the tree just representing the org, and everyone in the org (in the tree) having access to everything else in the tree, but limited by user roles.
Eddy Vluggen wrote:
"Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Authorization doesn't involve logins, Authentication does.