You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Richard Adams <ri...@researchspace.com> on 2016/07/07 08:20:18 UTC
ACLs in Shiro
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 <ro...@scsynergy.de> 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.
Re: ACLs in Shiro
Posted by Alessio Stalla <al...@manydesigns.com>.
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 <ri...@researchspace.com>
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 <ro...@scsynergy.de> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Piazza Matteotti, 2/11B | 16123 Genova (GE) | Italy