> On Sep 11, 2015, at 4:19 AM, Olaf Jentsch <[email protected]> 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 <[email protected]> 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.
