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.
