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.
Doesn't surprise. Something tells me we are getting our entities mixed up anyway. That is to say a user organization is not the same thing as a location. It makes sense that a user would be tied to a single user organization. I.e. BankX Tellers. But that user who is a member of the BankXTeller organization is authorized to work in many locations - i.e. Branch'es A and B. So if we were going to support such a requirement the following would have to be added/changed: 1. Add a new data type location. This would be a flat data structure (as opposed to user organziations which is a simple, directed graph. 2. Modify the fortress ftRls aux object class. Add ftLocs multi-occurring attribute to support carrying the list of allowed locations to scope a role to: ftLocs:brancha,branchb,branchc 3. Modify the fortress ftUserAttrs aux object class. Update the ftRC attribute to support carrying a multi-occurring attribute location for each role assignment. role1$0$0000$0000$$$$$$L[branchb,branchc] 4. Add an attribute to the User entity, location, to allow setting the user's location during signon 5. Add a validator that checks to ensure the user's location is a match for the role being activated. As I said before it is an interesting use case, but not sure it makes sense to do this. Adding another entity (location) and relationships (role to location) and (user-role to location) is non-trivial and maybe takes us away from our sweet spot (rbac).
