I don't remember the details, but I think Shiro can support this with user-defined Permission objects, rather than a custom isPermitted method which can be problematic. A Permission can imply() another Permission so there's an extension point where you get two Permission objects and can take a decision based on them. So if you manage to have UserPermissions and ItemPermissions you can do useful stuff. Sorry for the conciseness, I'm writing in a haste, if you're interested about the approach I can give some more info & pointers and actually think if it really suits your use case ;)
In my experience where an isPermitted method is unavoidable is when you might want to dynamically attach/detach permissions to unauthenticated users. Like, clickety-click and now guest can/cannot access such and such resource. But maybe /you/ have a solution for /that/ instead, and I've successfully hijacked the thread ;) On Thu, Jul 7, 2016 at 10:20 AM, Richard Adams <[email protected]> wrote: > Just on a slightly related note to the ‘attribute-based access control’ > thread: > > One problem that we’ve had with Shiro that we’ve had to implement > ourselves is instance-based permissions and Access Control Lists. > E.g. suppose you have a system with 100 Users and say 100 000 items > requiring authorisation, and each User can see about 1000 Items. Each Item > can be viewed by only a small number of Users. > It’s not really practical to add all the Item ids to permissions String on > the *User*, it gets very long and must be inefficient to process. > Instead we add the Permissions to the Item. > > So, instead of a Permission on the User: > ITEM:READ:item1,item2,item3……..item1000; // a very long string to store > in the DB for all users > we have Permissions on the Item > ITEM:READ:user1,user2,user3 // much shorter and faster to process > > But for some cases - e.g. if a User can view ALL items - then, yes, it’s > better (faster, less storage) to have the Permission on the User e.g. > ITEM:READ:* > > So we’ve found that depending on the characteristics and granularity of > the Permission, either approach can be useful. Therefore for all > authorisation checks we have a wrapper method: > > boolean isPermitted (Permissible item, User subject, Action action ){ > // 1. Check on user vi SecurityUtils.getSubject.isPermitted > (….. ) > // 2. If no user permission, check the item: > item.getACL().isPermitted(action, user); > } > > I’m sure many developers using Shiro will have faced the same sort of > issues, and maybe Shiro could be extended to include this sort of > functionality in its Authorizer system. > > Regards > Richard > > > > > On 7 Jul 2016, at 08:39, scSynergy <[email protected]> wrote: > > > > Sounds like a great idea. And while I am pretty sure you are planning to > > implement this and only forgot to mention it, I think we would need > '$role' > > in addition to '$user'. > > > > Concerning 'and Integer getClearanceLevel()' I would suggest a slightly > more > > versatile approach where getClearanceLevel() returns an Object instead > of an > > Integer. Then, each developer team could implement a sort of 'validator > > interface' which takes care of validating the returned Object to the > > predicate specified by @RequiresAttributes. That way, your team could > have > > your software check whether a user has a certain clearance level >= > Integer, > > and my team could check whether a role may access a certain document in > our > > MongoDB database == ObjectId > > (http://api.mongodb.com/java/current/org/bson/types/ObjectId.html). > > > > Shiro.ini might then read something like this: > > ... > > userValidator = your.package.name.YourClassName > > roleValidator = your.package.name.YourOtherClassName > > ... > > > > > > > > > > -- > > View this message in context: > http://shiro-user.582556.n2.nabble.com/Attribute-based-access-control-tp7581093p7581095.html > > Sent from the Shiro User mailing list archive at Nabble.com. > > -- *Alessio Stalla* | Software Architect M: +39 340 7824743 | T: +39 010 566441 | F: +39 010 8900455 [email protected] | www.manydesigns.com MANYDESIGNS s.r.l. Piazza Matteotti, 2/11B | 16123 Genova (GE) | Italy
