Working on integrating Shiro with Isis, I have the basic IniRealm working nicely, mapping users to roles though to permissions, using the basic WildcardPermission. What a given user can do is the sum of the permissions... in other words all very standard.
What I would like to do now is introduce the concept of "negative" or "vetoing" permissions. Using a custom subclass of WildcardPermission, I have defined the syntax: [!][permGroup/]packageName:className:memberName:r,w where the "!" implies a veto, and the permGroup implies a bunch of permissions to be evaluated together. For example: fred = pass, user joe = pass, read-only, user bill = admin read-only = !group1/*:*:*:w user = group1/*:ToDoItem:*:* admin = * means that fred has access to r/w for ToDoItem, but joe only has r permissions because of the read-only veto and is in the same permission group "group1". I've almost got this working using a bit of ThreadLocal hackery, however it depends on the ordering, with the vetos being applied before the non-vetos. Looking at the implementation of the IniRealm, I see that the role holds permissions in order (through use of a LinkedHashSet), however the order of a users roles are non-deterministic (because it uses a HashSet). This is a problem for me. ~~~ My question is therefore: could SimpleAuthorizationInfo be changed so that, when it lazily creates a HashSet (in addRole(...) or addRoles(...)), that it uses a LinkedHashSet? This would only change the internal implementaition, so perhaps could go into a point release? ~~~ A larger change to remove my threadlocal hackery might be to change the API so that there is a "PermissionEvaluationContext", acting a bit like a collecting parameter and allowing permissions to indicate whether they represent an "allow", a "veto", or neither. Then, the PermissionEvaluationContext could be asked what the outcome was. Thx Dan
