You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Olaf Jentsch <Ol...@condat.de> on 2015/09/09 17:04:11 UTC
User membership in different OrgUnit's
I was looking for the API method to add an OrgUnit to a user entity and found there ist only a set-method
User.setOu(ou)
to set only one organizational unit.
Why a user cannot be member of more than one OrgUnit's?
I think it is the normal case, that a user is working in different groups and has to be administered under different points of view.
Olaf Jentsch
RE: User membership in different OrgUnit's
Posted by Olaf Jentsch <Ol...@condat.de>.
No, I read it the same way like you.
-----Original Message-----
From: Shawn McKinney [mailto:smckinney@apache.org]
Sent: Friday, September 11, 2015 6:47 PM
To: fortress@directory.apache.org
Subject: Re: User membership in different OrgUnit's
> On Sep 11, 2015, at 4:19 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> This would not work for my use case, because I need one admin user allowed to administer to users from Org A and another one allowed to administer to users from Org B.
>
> Some of the users form Org A, but not all of them, needs to get the permissions from perm group B, which are administered by admin user B (resp. admin role B), but the decision which users are these is not in the hand of admin B. He should not see users, that don't need permissions from perm group B.
> It would be easy, if fortress would allow to set Org B as additional Org Unit to these users.
> Using ReviewMgr.findUsers(OrgUnitB) I could get these users.
>
> More cumbersome is to get the roles from role range from admin role B and then get the users by
> ReviewMgr.assignedUsers(roleX(endrange))
> I would use a general role in role range of admin role B to assign to users, which should be found from admin B to be administered.
> It's possible but it is a more complicated way for this use case.
>
Yes I understand the problem now, and yes there is more work for you - unfortunately. But if we fix this one problem, another will arise. Changing the mapping between a user and ou to multi-occuring, means we no longer have a way of knowing which org is the user’s primary. So now we get must store a flag on the ou assignment to say one is primary, the other is secondary affiliation. Doable, but with each additional relationship (between entries in LDAP) so increases the complexity of maintaining because referential integrity isn’t guaranteed across LDAP implementations. And how many secondary orgs may the user be assigned to. One? Unlimited?
It is an interesting idea. But we need to give it careful consideration to ensure it doesn’t make the solution brittle or bring up other unsolved corner cases. I’d like to hear what others think on this issue. In the meantime, I’m sure we can come up with a workaround for your problem.
>
> On Sep 11, 2015, at 4:19 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
>
> Is it ARBAC or is it Fortress what don't allow more than one Org Unit per user?
Here is the draft:
http://profsandhu.com/journals/tissec/p113-oh.pdf
With user orgs being described on page 125. Excerpt follows below. I believe the answer is ‘no’, the model specifies each user belongs to one and only one organization. Have a look, and let me know if you see it a different way.
Definition 4.1
(OS-U)
A user organization structure is an organization unit (OT) hierarchy represented as a user pool:
OS-U ⊆ OT× OT, and
* has a partially ordered tree structure;
* has a maximal organization unit, and ∀ ot ∈ OT, ot has only one direct parent;
* UUA ⊆ U × OT is a set of user-organization unit assignments;
* members : OT → 2U is a function mapping an organization unit to a set of users, and members(ot) = {u : U | (u, ot) ∈ UUA};
* members ∗ : OT → 2U is a function mapping an organization unit to a set of users with inheritance hierarchy in OS-U, and members∗ (ot) = {u : U | (∃ot’ ≤ ot), (u, ot) ∈ UUA}.
An OS-U contains the users who are pre-assigned by the HR group in an organization. Figure 12 shows an example of OS-U. If Tom is a member of PJ 1, it may mean that he has a job position in project 1. If John is a member of ED, it may mean that he is the director of the engineering department. As OS-U has a tree structure and the characteristic of inheritance, Tom is also a member of ED and PRD.
Re: User membership in different OrgUnit's
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 11, 2015, at 4:19 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> This would not work for my use case, because I need one admin user allowed to administer to users from Org A and another one allowed to administer to users from Org B.
>
> Some of the users form Org A, but not all of them, needs to get the permissions from perm group B, which are administered by admin user B (resp. admin role B), but the decision which users are these is not in the hand of admin B. He should not see users, that don't need permissions from perm group B.
> It would be easy, if fortress would allow to set Org B as additional Org Unit to these users.
> Using ReviewMgr.findUsers(OrgUnitB) I could get these users.
>
> More cumbersome is to get the roles from role range from admin role B and then get the users by
> ReviewMgr.assignedUsers(roleX(endrange))
> I would use a general role in role range of admin role B to assign to users, which should be found from admin B to be administered.
> It's possible but it is a more complicated way for this use case.
>
Yes I understand the problem now, and yes there is more work for you - unfortunately. But if we fix this one problem, another will arise. Changing the mapping between a user and ou to multi-occuring, means we no longer have a way of knowing which org is the user’s primary. So now we get must store a flag on the ou assignment to say one is primary, the other is secondary affiliation. Doable, but with each additional relationship (between entries in LDAP) so increases the complexity of maintaining because referential integrity isn’t guaranteed across LDAP implementations. And how many secondary orgs may the user be assigned to. One? Unlimited?
It is an interesting idea. But we need to give it careful consideration to ensure it doesn’t make the solution brittle or bring up other unsolved corner cases. I’d like to hear what others think on this issue. In the meantime, I’m sure we can come up with a workaround for your problem.
>
> On Sep 11, 2015, at 4:19 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
>
> Is it ARBAC or is it Fortress what don't allow more than one Org Unit per user?
Here is the draft:
http://profsandhu.com/journals/tissec/p113-oh.pdf
With user orgs being described on page 125. Excerpt follows below. I believe the answer is ‘no’, the model specifies each user belongs to one and only one organization. Have a look, and let me know if you see it a different way.
Definition 4.1
(OS-U)
A user organization structure is an organization unit (OT) hierarchy represented as a user pool:
OS-U ⊆ OT× OT, and
* has a partially ordered tree structure;
* has a maximal organization unit, and ∀ ot ∈ OT, ot has only one direct parent;
* UUA ⊆ U × OT is a set of user-organization unit assignments;
* members : OT → 2U is a function mapping an organization unit to a set of users, and members(ot) = {u : U | (u, ot) ∈ UUA};
* members ∗ : OT → 2U is a function mapping an organization unit to a set of users with inheritance hierarchy in OS-U, and members∗ (ot) = {u : U | (∃ot’ ≤ ot), (u, ot) ∈ UUA}.
An OS-U contains the users who are pre-assigned by the HR group in an organization. Figure 12 shows an example of OS-U. If Tom is a member of PJ 1, it may mean that he has a job position in project 1. If John is a member of ED, it may mean that he is the director of the engineering department. As OS-U has a tree structure and the characteristic of inheritance, Tom is also a member of ED and PRD.
RE: User membership in different OrgUnit's
Posted by Olaf Jentsch <Ol...@condat.de>.
This would not work for my use case, because I need one admin user allowed to administer to users from Org A and another one allowed to administer to users from Org B.
Some of the users form Org A, but not all of them, needs to get the permissions from perm group B, which are administered by admin user B (resp. admin role B), but the decision which users are these is not in the hand of admin B. He should not see users, that don't need permissions from perm group B.
It would be easy, if fortress would allow to set Org B as additional Org Unit to these users.
Using ReviewMgr.findUsers(OrgUnitB) I could get these users.
More cumbersome is to get the roles from role range from admin role B and then get the users by
ReviewMgr.assignedUsers(roleX(endrange))
I would use a general role in role range of admin role B to assign to users, which should be found from admin B to be administered.
It's possible but it is a more complicated way for this use case.
Is it ARBAC or is it Fortress what don't allow more than one Org Unit per user?
Olaf Jentsch
-----Original Message-----
From: Shawn McKinney [mailto:smckinney@apache.org]
Sent: Friday, September 11, 2015 3:40 AM
To: fortress@directory.apache.org
Subject: Re: User membership in different OrgUnit's
>
> On Sep 10, 2015, at 6:30 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> I would like to seperate different administrative tasks for different permissions but to show the same user for different administrative roles.
>
> A user u has RoleA in order to get permissions in perm group PA.
> I create an admin role AdminA, which can assign RoleA to users in Org
> Unit OUA in order to get permissions from perm group A, so happened for user u when AdminA assigned RoleA to him.
>
> There is a new application with his own permissions organized in perm group B an assigned to RoleB.
> I would like to create a similar admin role AdminB, which can assign RoleB to users in OUB in order to get permissions from perm group B.
>
> But now the user u in OUA needs the permissions from perm group B. AdminB cannot assign RoleB to him, because user u is in OUA and not in OUB.
> And I don't want AdminB watching all users in OUA, he only should see users from OUB.
>
> Fortress should allow the assignment of several OU's for this use case or is something wrong in my structure?
You could achieve nearly the same thing by structuring the ous hierarchically.
For example you could have a structure like this:
User Org A: parent X
User Org B: parent X
Then you could add a new admin role that has X as the user ou assignment. Assignees of this role would be allowed to administer to users from both Org A and Org B.
Would that work?
Shawn
Re: User membership in different OrgUnit's
Posted by Shawn McKinney <sm...@apache.org>.
>
> On Sep 10, 2015, at 6:30 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> I would like to seperate different administrative tasks for different permissions but to show the same user for different administrative roles.
>
> A user u has RoleA in order to get permissions in perm group PA.
> I create an admin role AdminA, which can assign RoleA to users in Org Unit OUA in order to get permissions from perm group A,
> so happened for user u when AdminA assigned RoleA to him.
>
> There is a new application with his own permissions organized in perm group B an assigned to RoleB.
> I would like to create a similar admin role AdminB, which can assign RoleB to users in OUB in order to get permissions from perm group B.
>
> But now the user u in OUA needs the permissions from perm group B. AdminB cannot assign RoleB to him, because user u is in OUA and not in OUB.
> And I don't want AdminB watching all users in OUA, he only should see users from OUB.
>
> Fortress should allow the assignment of several OU's for this use case or is something wrong in my structure?
You could achieve nearly the same thing by structuring the ous hierarchically.
For example you could have a structure like this:
User Org A: parent X
User Org B: parent X
Then you could add a new admin role that has X as the user ou assignment. Assignees of this role would be allowed to administer to users from both Org A and Org B.
Would that work?
Shawn
RE: User membership in different OrgUnit's
Posted by Olaf Jentsch <Ol...@condat.de>.
I would like to seperate different administrative tasks for different permissions but to show the same user for different administrative roles.
A user u has RoleA in order to get permissions in perm group PA.
I create an admin role AdminA, which can assign RoleA to users in Org Unit OUA in order to get permissions from perm group A,
so happened for user u when AdminA assigned RoleA to him.
There is a new application with his own permissions organized in perm group B an assigned to RoleB.
I would like to create a similar admin role AdminB, which can assign RoleB to users in OUB in order to get permissions from perm group B.
But now the user u in OUA needs the permissions from perm group B. AdminB cannot assign RoleB to him, because user u is in OUA and not in OUB.
And I don't want AdminB watching all users in OUA, he only should see users from OUB.
Fortress should allow the assignment of several OU's for this use case or is something wrong in my structure?
Olaf Jentsch
-----Original Message-----
From: Shawn McKinney [mailto:smckinney@apache.org]
Sent: Wednesday, September 09, 2015 10:57 PM
To: fortress@directory.apache.org
Subject: Re: User membership in different OrgUnit's
> On Sep 9, 2015, at 3:30 PM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> In the Fortress API I found only one method in the class
> org.apache.directory.fortress.core.rbac.User
> to set a one-to-one relationship between one user and one OrgUnit.
>
> How can I achieve a one-to-many relationship without using LDAP API directly to set the user entity?
Sorry if I was not clear before. You are right, fortress will not allow it. My question is, why is this a problem? i.e. what is the use case that we can’t satisfy today using this data model?
Re: User membership in different OrgUnit's
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 9, 2015, at 3:30 PM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> In the Fortress API I found only one method in the class
> org.apache.directory.fortress.core.rbac.User
> to set a one-to-one relationship between one user and one OrgUnit.
>
> How can I achieve a one-to-many relationship without using LDAP API directly to set the user entity?
Sorry if I was not clear before. You are right, fortress will not allow it. My question is, why is this a problem? i.e. what is the use case that we can’t satisfy today using this data model?
RE: User membership in different OrgUnit's
Posted by Olaf Jentsch <Ol...@condat.de>.
In the Fortress API I found only one method in the class
org.apache.directory.fortress.core.rbac.User
to set a one-to-one relationship between one user and one OrgUnit.
How can I achieve a one-to-many relationship without using LDAP API directly to set the user entity?
Olaf Jentsch
-----Original Message-----
From: Shawn McKinney [mailto:smckinney@apache.org]
Sent: Wednesday, September 09, 2015 5:23 PM
To: fortress@directory.apache.org
Subject: Re: User membership in different OrgUnit's
> On Sep 9, 2015, at 10:04 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> I was looking for the API method to add an OrgUnit to a user entity and found there ist only a set-method
> User.setOu(ou)
> to set only one organizational unit.
>
> Why a user cannot be member of more than one OrgUnit's?
> I think it is the normal case, that a user is working in different groups and has to be administered under different points of view.
You are right - there’s a one-to-many relationship between users and their ous.
Do you have a scenario for why this can’t be?
Shawn
Re: User membership in different OrgUnit's
Posted by Shawn McKinney <sm...@apache.org>.
> On Sep 9, 2015, at 10:04 AM, Olaf Jentsch <Ol...@condat.de> wrote:
>
> I was looking for the API method to add an OrgUnit to a user entity and found there ist only a set-method
> User.setOu(ou)
> to set only one organizational unit.
>
> Why a user cannot be member of more than one OrgUnit's?
> I think it is the normal case, that a user is working in different groups and has to be administered under different points of view.
You are right - there’s a one-to-many relationship between users and their ous.
Do you have a scenario for why this can’t be?
Shawn