On 12/12/2014 12:10 PM, Nicolas Eirea wrote: > Yes, but our reality also require that an User could have more than one > userou associated. > > Example: a bank teller has the role "Teller" activated in branch "A" and > "B" but not in branch "C". Or other roles for some branches and others not.
A couple more thoughts. First, this can be done simply by scoping each role to a branch. For example we could have a tellera, tellerb and tellerc roles. Simply assign the role to a given user as needed. Furthermore more those roles can be constrained as previously described. For example these roles would use dynamic separation of duty constraints to limit activation to one and only one role from the set. (a teller can only be in one branch at a time) This sample web app, written using apache wicket, uses fortress to enforce this kind of policy: https://github.com/shawnmckinney/apache-fortress-demo the rbac policy file is here: https://github.com/shawnmckinney/apache-fortress-demo/blob/master/apache-fortress-demo-load-policy.xml You will notice the roles include page and customer number in the name. For page, think branch. The customer number was included so the permission checks can be fine-grained. e.g. permission : objectname=page1, opname=update, objectid=123 the role to grant perm is page1_123 *** The obvious drawback to the above is one role for each page (teller) and customer number combination. In a real-world use case this would lead to many roles which creates a different problems. One could argue if you managed this in another way, i.e. permissions tied directly to the user, you would have the same problem - if not worse. Everything has trade-offs. *** Closing thoughts: Fortress implement ansi incits 359 which does not provide a means to control role activation via arbitrary attributes - i.e. location. ansi incits 494 however does allow these kinds of constraints and indeed specifically mentions a location based constraint. Maybe one day we'll add incits 494 to fortress. >From the spec doc: "5.4.1 Description Restriction on which roles may be active simultaneously Restriction on which users may activate a given pair of roles at the same time Restriction on roles or permissions that depends on the value of an attribute Dynamic Constraints Extending the dynamic constraints of RBAC (INCITS 359), the RPE dynamic constraints consist of role-role, user-role, and attribute-sensitive constraints. Dynamic constraints are constraints that take effect at run time. They are distinguished from static constraints, which take effect prior to run time. Dynamic constraints are enforced by access control mechanisms. They act on some components of the RBAC reference model, namely users and roles. Dynamic constraints are localized to a user session. 5.4.1.1 Role-Role (Dynamic) Role-role constraints hold between roles or sets of roles. They can support policies that involve limitations on which combinations of roles may be activated in any user session. 5.4.1.2 User-Role (Dynamic) User-role constraints hold between users and roles. They can support policies that involve limitations on which combinations of roles may be activated by a given user. 5.4.1.3 Attribute-sensitive (Dynamic) Attribute-sensitive constraints apply to roles or permissions. They can support policies that involve limitations on which particular roles may be activated or which permissions may be used in a given user session. 5.4.1.3.1 Time of Day Time of Day constraints control the time at which a role may be activated. 5.4.1.3.2 Location Location constraints control the user location at which a role may be activated. 5.4.1.3.3 Purpose of Use Purpose of use constraints specify a reason for requesting a particular access via a role. Examples include privacy, patient consent, and emergency access. 5.4.1.3.4 User Class User class constraints control the user class that may exercise a given permission. 5.4.1.3.5 Data Value Data value constraints control an access control decision based on data values, e.g., values in a database. 5.4.1.3.6 Identity Type Identity type constraints use a business decision-making process to determine what the user’s role is." (above excerpt captured from INCITS 494-2012)
