shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <cla...@xenei.com>
Subject Re: Hierarchical permissions and the hasAny check
Date Tue, 16 Jan 2018 07:18:48 GMT
Ghislain,

On further reflection, it seems that your proposal is a change to the
WildcardFilter while the change I am proposeing is a change to the Subject
implementation.  The change has to be on subject as that is the only
interface the application has to the user's permissions.  The other
alternative is to provide access to the set of user permissions so that any
arbitrary function could be performed.

I suppose a 3rd would be to provide a method that takes a lambda function
that filters a stream of permissions.  Subject then returns true if there
are any matches/false otherwise.

The current implies method could be implemented as such a filter.

Claude

On Mon, Jan 15, 2018 at 11:07 PM, Claude Warren <claude@xenei.com> wrote:

> Ghislain,
>
> I can see the benefit of your pattern and was thinking about it this AM.
> However, my requirement is different in that I don't necessarily know the
> depth of the permisisons.
>
> In specific I am looking at how to implement the Jena Permissions
> SecurityEvaluator class using Shiro permissions only.  The current example
> code uses Shiro for auth but not authz.
>
> Using your pattern it would be possible to do some checks that can not now
> be done efficiently and agree that it has merit.
>
> Slightly off topic here: how many people are actively working on Shiro?
>
> Claude
>
> On Mon, Jan 15, 2018 at 8:37 PM, Gh T <ghislain.touratier@gmail.com>
> wrote:
>
>> Hello Claude,
>>
>> Your requirement looks a bit like a proposal I made a long time ago, the
>> idea was to introduce an "any" operator ("?") in the wildcard permission
>> syntax in order to be able to check permissions like "is the user allowed
>> to do something, whatever it is, on this resource?".
>> In your particular example this solution may work if you know by advance
>> the maximal depth of the permission levels you want to check.
>> For instance, if your subject has permissions up to 5 levels like
>> "root:a:b:c:d", you can ask question like "Is the user allowed to do
>> anything below "root:a"" by testing the permission "root:a:?:?:?".
>>
>> With a small modification of code, you can probably give it a more
>> hierarchical meaning and be able to request the same thing by just testing
>> "root:a:?" which should be implied by permissions like "root:a:*",
>> "root:a:b:c:d:e:g,h:1,5" or whatever permissions that are below "root:a".
>>
>> If you want more details, the original ticket is here:
>> https://issues.apache.org/jira/browse/SHIRO-438
>>
>> Best regards,
>> Ghislain
>>
>>
>>
>> 2018-01-10 13:33 GMT+01:00 claude.warren@wipro.com <
>> claude.warren@wipro.com>
>> :
>>
>> > I have a suggestion for improvement of permissions checking for
>> > permissions with an hierarchical structure.
>> >
>> >
>> > For purposes of this discussion I will use the WildcardPermission as an
>> > example but the discussion applies to any hierarchically structured
>> > permission.
>> >
>> >
>> > In some situations, when processing requests for hierarchically
>> structured
>> > data with matching permissions it would speed up processing to know if
>> > there are any permissions further down the tree.
>> >
>> >
>> > Assume a tree structure with large subtrees on nodes A and B off the
>> root.
>> >
>> >
>> > If the code is producing a list of all leaf nodes the Subject can read
>> it
>> > would speed up processing significantly if the application code could
>> check
>> > to see if the user has any access to any node in A.
>> >
>> >
>> > Currently the WildcardPermission implementation of implies() returns the
>> > following:
>> >
>> >
>> > {noformat}
>> > Subj       Checked
>> > Perm       Perm      Result
>> > ----------------------------
>> > root       root      true
>> > root       root:*    true
>> > root       root:a    true
>> > root       root:a:*  true
>> > root       root:b    true
>> > root       root:b:*  true
>> >
>> > root:*     root      true
>> > root:*     root:*    true
>> > root:*     root:a    true
>> > root:*     root:a:*  true
>> > root:*     root:b    true
>> > root:*     root:b:*  true
>> >
>> > root:a     root      false
>> > root:a     root:*    false
>> > root:a     root:a    true
>> > root:a     root:a:*  true
>> > root:a     root:b    false
>> > root:a     root:b:*  false
>> >
>> > root:a:*   root      false
>> > root:a:*   root:*    false
>> > root:a:*   root:a    true
>> > root:a:*   root:a:*  true
>> > root:a:*   root:b    false
>> > root:a:*   root:b:*  false
>> >
>> > root:b     root      false
>> > root:b     root:*    false
>> > root:b     root:a    false
>> > root:b     root:a:*  false
>> > root:b     root:b    true
>> > root:b     root:b:*  true
>> >
>> > root:b:*   root      false
>> > root:b:*   root:*    false
>> > root:b:*   root:a    false
>> > root:b:*   root:a:*  false
>> > root:b:*   root:b    true
>> > root:b:*   root:b:*  true
>> >
>> > {noformat}
>> >
>> >
>> > There is no mechanism by which I can grant a permission to a subject and
>> > then ask if they have access to anything below a specific point.  As a
>> > concrete example.  I want to be able to check that the user with
>> > permissions "root:a" has access to something  below "root".
>> >
>> >
>> > There is no combination that I can discover where I can set this up.
>> >
>> >
>> > I am proposing a couple of changes.
>> >
>> >   1.  Introduce a HierarchicalPermissions interface to mark such
>> > permissions.
>> >   2.  create a method on Subject that takes a permission and determines
>> if
>> > the user has any permissions at that level or below.
>> >
>> >
>> > Lets call that method "hasRestriction()" for the rest of this
>> discussion.
>> > hasRestriction() will return true if there are any explicit permissions
>> > noted at or below the level
>> >
>> >
>> > When the subject.hasRestriction() is called the above tables would have
>> > the following results
>> >
>> >
>> > {noformat}
>> >
>> > Subj       Checked
>> > Perm       Perm      Result
>> > ----------------------------
>> > root       root      true
>> > root       root:*    false
>> > root       root:a    false
>> > root       root:a:*  false
>> > root       root:b    false
>> > root       root:b:*  false
>> >
>> > root:*     root      true
>> > root:*     root:*    true
>> > root:*     root:a    true
>> > root:*     root:a:*  false
>> > root:*     root:b    true
>> > root:*     root:b:*  false
>> >
>> > root:a     root      true
>> > root:a     root:*    true
>> > root:a     root:a    true
>> > root:a     root:a:*  false
>> > root:a     root:b    false
>> > root:a     root:b:*  false
>> >
>> > root:a:*   root      true
>> > root:a:*   root:*    true
>> > root:a:*   root:a    true
>> > root:a:*   root:a:*  true
>> > root:a:*   root:b    true
>> > root:a:*   root:b:*  true
>> >
>> > root:b     root      true
>> > root:b     root:*    true
>> > root:b     root:a    false
>> > root:b     root:a:*  false
>> > root:b     root:b    true
>> > root:b     root:b:*  false
>> >
>> > root:b:*   root      true
>> > root:b:*   root:*    true
>> > root:b:*   root:a    false
>> > root:b:*   root:a:*  false
>> > root:b:*   root:b    true
>> > root:b:*   root:b:*  true
>> >
>> >
>> > {noformat}
>> >
>> >
>> > With this method available I can ask the following in the code.
>> >
>> >
>> > {noformat}
>> >
>> >
>> > if (subject.isPermitted( perm ))
>> >
>> > {
>> >
>> >     if (subject.hasRestriction( perm )) {
>> >
>> >        // code with deeper checking
>> >
>> >     } else {
>> >
>> >       // just get the data here as there are no further restrictions.
>> >
>> >     }
>> >
>> > } else {
>> >
>> >     // no access
>> >
>> > }
>> >
>> >
>> > {noformat}
>> >
>> >
>> > Thoughts?
>> >
>> >
>> > Claude
>> >
>> > The information contained in this electronic message and any attachments
>> > to this message are intended for the exclusive use of the addressee(s)
>> and
>> > may contain proprietary, confidential or privileged information. If you
>> are
>> > not the intended recipient, you should not disseminate, distribute or
>> copy
>> > this e-mail. Please notify the sender immediately and destroy all
>> copies of
>> > this message and any attachments. WARNING: Computer viruses can be
>> > transmitted via email. The recipient should check this email and any
>> > attachments for the presence of viruses. The company accepts no
>> liability
>> > for any damage caused by any virus transmitted by this email.
>> > www.wipro.com
>> >
>> > ______________________________________________________________________
>> > This email has been scanned by the Symantec Email Security.cloud
>> service.
>> > For more information please visit http://www.symanteccloud.com
>> > ______________________________________________________________________
>>
>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>



-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message