Thank you very much for your complete responses Shawn, have been very helpful.
2014-12-15 11:28 GMT-02:00 Shawn McKinney <[email protected]>: > > 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) >
