You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@shiro.apache.org by Philippe Laflamme <tw...@gmail.com> on 2010/11/11 15:34:31 UTC

Question regarding WildcardPermission

Hi,

I've got a question regarding the current implementation of
WildcardPermission.

Currently, the following holds true:

thing:read:foo implies thing:read:foo:bar

Which basically means that if you can "read" the "foo" "thing", you can also
"read" the "bar" "thing" in the "foo" "thing".

But the reverse statement does not hold true:

thing:read:foo:bar does NOT imply thing:read:foo

Meaning that if you can read "bar" you can't read "foo".

Now, at first I thought that it made sense, but after thinking about it, I
can't figure out what's a valid use case for this.

My reasoning is based on the fact that "bar" in this situation is something
that belongs to "foo" (otherwise, I would have a separate permission domain,
ie: otherthing:read:bar). So if "bar" only exists if "foo" also does, what
is the valid use case of allowing access to "bar" but not to "foo"?

Note that saying that the "longer" permission implies the "shorter" DOES NOT
imply other longer permissions. That is,

thing:read:foo:bar implies thing:read:foo --> true
thing:read:foo:bar implies thing:read:foo:foobar --> false

Is my reasoning valid?

I've created my own Permission implementation that does exactly that and it
behaves as expected (I can read foo, bar, but not foobar). I'm wondering
what is a valid use-case for NOT wanting this behaviour?

Thanks!
Philippe
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5728829.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Philippe Laflamme <tw...@gmail.com>.

Hi Tamas,

You're right, my data is represented as a tree and accessing leaves requires
permissions to go through the branches. Furthermore, permissions can be
assigned at the leaf level (one can grant permissions on a single leaf in
the whole tree).

This is probably not a common use-case, but certainly not a unique one
either. Lots of things are/can be represented as a tree structure.

I'll have to investigate this further, but I'd welcome any advice. Has
anyone gone down this path before, with Shiro or other security systems?

Thanks!
Philippe
-- 
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5730329.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Tamás Cservenák <ta...@cservenak.net>.

On Thu, Nov 11, 2010 at 8:31 PM, Les Hazlewood <lh...@apache.org>wrote:

> I'll give an example of why the existing behavior makes sense to me:
>
> user:read:jsmith:username
>
> Just because I can read (view) the jsmith user's username does _not_ imply
> that I should be able to see all of jsmith's user data.  Perhaps I shouldn't
> be able to see the user record's password field for example.
>

I think that would be "horizontal" way (assuming username and password are
on same "level" of some logical hierarchy. What Philippe says, is that he
needs "vertical" way, from child to parent (up to root) to have permissions
implied... And that makes sense: you need to access parents of a tree to get
to the child you have access granted. WildcardPermission surely does not
apply any "hierarchy" assumptions.

But it is interesting idea: let consider a basic tree structure, and what
actually Philippe want, is to grant access/permissions on single node, and
have the "path" opened from root to that node. Converting things like UI,
menus, wizards etc is very easy to represent as trees, so this would be
interesting feature.

In that way, the permissions may be considered as some hierarchical URI or
maybe "path", and the path elements would correspond to some domains of your
app, like in his example:

app:taksLists/cstamas/T01:read

where "taskLists" in my application may apply to something like "may open
the Task Lists Panel", "cstamas" corresponds to taskList with ID "cstamas"
and "T01" denotes the ID of the task in question. Naturally, in my fictive
app, granting this single permission to user "philippe", I would be able to
allow him all the neede UI "route" to get to the information he needs.

But i think this is not really in the scope of Shiro.
Also, this would be an interesting exercise to implement one ;)
If you stick to trees, you could have different strategies: "propagateUp"
(applies to node and a single path from the node to the root),
"propagateDown" (applies to given node and all children below), etc... a
nice game, with powerful possibilities :D

Thanks,
~t~

Re: Question regarding WildcardPermission

Posted by Tamás Cservenák <ta...@cservenak.net>.

Hi Les,

without implying or answering to your concerns below (I do agree with your
concerns), and just for fun, last night I played a bit, and created "spatial
permissions" for Shiro :D

https://github.com/cstamas/shiro-extras


You can "grant" permissions based on points in space :D :D  ("space" as the
most generic definition). Examples with 2d and 3d space, and a special space
defined on trees (n-trees) that actually implements Philippe's case and much
more. And some examples with finite spaces too.



It was really fun, but am not sure at all, would it have any practical
usage. For best "description" (last night was unable to type javadoc, one
hand was occupied with a beer keg), look at the UTs.

Also, there is a funny part, about spatiality-misuse, but allowing you to
define a complete sets of beneficiaries with only a few permissions.

Disclaimer: this as is, may not be used in flight control, but I did not
test it completely with shiro either, so if this proves unworkable, don't
blame me! It was a long time when I was playing with Shiro's internals.
Also, this is unfinished. To utilize this, you need more stuff, like some
SpatialPermissionProvider etc.

Have fun,
~t~

On Fri, Nov 12, 2010 at 1:26 AM, Les Hazlewood <lh...@apache.org>wrote:

> Now that I've thought about this a bit more, I'm curious - might you
> be tying the concept of access too closely to the UI representation?
> To me, there seems to be a high risk of tight coupling in this case.
> Let me explain.
>
> Let's use Tamás's previous example of app:taksLists/cstamas/T01:read
>
> We want to first check to see if the user is currently permitted to
> view the taskList with id 'cstamas'.  If so, this means the user
> should be able to show the 'task lists panel'.
>
> e.g. in existing Shiro capabilities:
>
> if ( subject.isPermitted("taskList:read:cstamas") ) {
>    //enable the panel
> }
>
> Then, we additionally want to check to see if the current user is able
> to see the task with ID 'T01'.  That translates (logically) to another
> check:
>
> if ( subject.isPermitted("task:read:T01") ) {
>    //show the task with id T01
> }
>
> Both of these checks reflect what you're actually trying to accomplish
> in the sense of raw functionality.  They are not forced to mirror how
> you might represent this in the UI.  For example - what if your UI
> changes or is modified to where the tree might not make as much sense?
>  Using my example, you don't have to change how the permissions are
> represented in your data store, because they're not tightly coupled to
> what the UI is trying to do.  This decoupled approach is likely to be
> much more resilient/robust.
>
> Also note that in the filesystem example, just because I have read
> access to /a/b/c/d.txt, it does not necessarily mean I have read
> access to the 'b' directory.  I may not be able to see anything in the
> 'b' directory - it just means that I can reference b in the context of
> getting to d.txt.  For example, you can try this in linux:
>
> (as root):
> # mkdir /tmp/a/b/c
> # touch /tmp/a/b/c/d.txt
> # chmod ugo+r /tmp/a/b/c/d.txt
> # chmod go-r /tmp/a/b
>
> (as a non-root user):
> > less /tmp/a/b/c/d.txt
> (you can read the file fine)
>
> > cd /tmp/a/b
> > ls
> (permission denied).
>
> Because I have 'execute' (+x) permission on the b directory, I can
> reference files below it for which I have prior knowledge.  But
> because I don't have read permission for the 'b' directory, I can't
> see anything in it.
>
> Anyway - it's an interesting point.  I'd just caution about coupling
> the permission structure and its use in security policies too closely
> with UI/client-level concerns if you can avoid it.  That would seem
> brittle to me.
>
> Les
>
> On Thu, Nov 11, 2010 at 3:55 PM, Les Hazlewood <lh...@apache.org>
> wrote:
> > Philippe and Tamás,
> >
> > I think your ideas are great actually and the idea makes quite a lot
> > of sense depending on the application's needs.
> >
> > I don't see why there couldn't be something like a TreePermission
> > implementation in Shiro that people could choose to use if they
> > wanted.  It would have to be designed very well to ensure it is
> > flexible, but it's a very interesting idea.
> >
> > If anyone wants to give this a shot, please open a Jira issue to keep
> > track of it and discuss it on the dev list.
> >
> > Great stuff!
> >
> > Les
> >
> > On Thu, Nov 11, 2010 at 1:21 PM, Philippe Laflamme <tw...@gmail.com>
> wrote:
> >>
> >> I did succeed in implementing my own Permission class and making my
> use-case
> >> work, so thanks a lot for Shiro's flexibility. In that respect, it's
> really
> >> nicely done. I did have to copy/paste some WildcardPermission code which
> I
> >> would rather not. It may need some additional protected methods; I'll
> try to
> >> make a patch.
> >>
> >> I realize now that "bubbling-up" permissions is not appropriate in all
> >> situations. I'd like to get some input on how I can implement my
> use-case
> >> with Shiro.
> >>
> >> The main issue I have is that in order to access finer-grained
> permissions,
> >> I first need to test the coarser-grained ones. Using a file-system as an
> >> analogy (/a/b/c): to reach the 'c' folder, I have to read 'a', 'b'
> first.
> >> But I want to manage permissions at the "c" level, meaning I want to
> grant
> >> access to "c" which would then imply access to "a" and "b".
> >>
> >> I now realize that some permissions shouldn't bubble up. For example, if
> I
> >> grant write to 'c', I don't want that to mean write to 'b' and 'a' as
> well.
> >> That said, I would want it to mean read 'b' and 'a' since the user would
> >> need to "reach" 'c' in order to write to it.
> >>
> >> So in Shiro terms, I guess what I'm saying is:
> >>
> >> fs:read:a:b:c implies fs:read:a:b and fs:read:a
> >> fs:write:a:b:c implies fs:read:a:b and fs:read:a
> >> more generally
> >> fs:*:a:b:c implies fs:read:a:b and fs:read:a
> >>
> >> The system would allow read on "parent" entities when you have any
> >> permission on one of its child. It bubbles up, but "downgrades" the
> >> permission.
> >>
> >> Obviously, this is very different from WildcardPermissions and is very
> >> specific to my use-case...
> >>
> >> Any thoughts on this from anyone?
> >> --
> >> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5730302.html
> >> Sent from the Shiro User mailing list archive at Nabble.com.
> >
>

Re: Question regarding WildcardPermission

Posted by Philippe Laflamme <tw...@gmail.com>.

Hi Les,

Thanks for your input.

I agree that tying the permissions to UI constructs is a bad idea. In my
situation though, it really maps to how the data model is structured (ie: to
get a Task instance, I must first obtain a TaskList instance). Obviously,
the UI reflects this also. Tree nodes are only accessible through their
parent node.

Furthermore, the use-case is to manage permissions at the leaf level (read
the Task) and have the implementation imply whatever other permissions are
required to handle this.

POSIX file-system solved the issue by splitting the "read" permission in
two: 'open' (x) vs. 'read contents' (r). 'cd' tests the 'open' permission
while 'ls' tests the 'read contents' permission.

If you don't have 'open' (x) on one of the parent paths, you can't reach the
children, regardless of the rights you have on those. It's left to the user
to set the 'x' on all parents (which is a huge pain, but completely
understandable in a file-system context). So looking at the situation this
way, it's really similar to my case: provide 'read' to a child implies
'open' on all parents.

So in a TreePermission scheme, there would need to be some kind of
distinction between reading a node and listing its children; similar to 'r'
and 'x' in POSIX. Having a 'r' permission on a child could imply an 'x'
permission on the parents.

Sound reasonable?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5733532.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Philippe Laflamme <tw...@gmail.com>.

Hi Les,

Thanks for your input.

Furthermore, the use-case is to manage permissions at the leaf level (read
the Task) and have the implementation imply whatever other permissions are
required to handle this.

POSIX file-system solved the issue by splitting the "read" permission in
two: 'open' (x) vs. 'read contents' (r). 'cd' tests the 'open' permission
while 'ls' tests the 'read contents' permission.

Sound reasonable?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5733533.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Les Hazlewood <lh...@apache.org>.

Now that I've thought about this a bit more, I'm curious - might you
be tying the concept of access too closely to the UI representation?
To me, there seems to be a high risk of tight coupling in this case.
Let me explain.

Let's use Tamás's previous example of app:taksLists/cstamas/T01:read

We want to first check to see if the user is currently permitted to
view the taskList with id 'cstamas'.  If so, this means the user
should be able to show the 'task lists panel'.

e.g. in existing Shiro capabilities:

if ( subject.isPermitted("taskList:read:cstamas") ) {
    //enable the panel
}

Then, we additionally want to check to see if the current user is able
to see the task with ID 'T01'.  That translates (logically) to another
check:

if ( subject.isPermitted("task:read:T01") ) {
    //show the task with id T01
}

Both of these checks reflect what you're actually trying to accomplish
in the sense of raw functionality.  They are not forced to mirror how
you might represent this in the UI.  For example - what if your UI
changes or is modified to where the tree might not make as much sense?
 Using my example, you don't have to change how the permissions are
represented in your data store, because they're not tightly coupled to
what the UI is trying to do.  This decoupled approach is likely to be
much more resilient/robust.

Also note that in the filesystem example, just because I have read
access to /a/b/c/d.txt, it does not necessarily mean I have read
access to the 'b' directory.  I may not be able to see anything in the
'b' directory - it just means that I can reference b in the context of
getting to d.txt.  For example, you can try this in linux:

(as root):
# mkdir /tmp/a/b/c
# touch /tmp/a/b/c/d.txt
# chmod ugo+r /tmp/a/b/c/d.txt
# chmod go-r /tmp/a/b

(as a non-root user):
> less /tmp/a/b/c/d.txt
(you can read the file fine)

> cd /tmp/a/b
> ls
(permission denied).

Because I have 'execute' (+x) permission on the b directory, I can
reference files below it for which I have prior knowledge.  But
because I don't have read permission for the 'b' directory, I can't
see anything in it.

Anyway - it's an interesting point.  I'd just caution about coupling
the permission structure and its use in security policies too closely
with UI/client-level concerns if you can avoid it.  That would seem
brittle to me.

Les

On Thu, Nov 11, 2010 at 3:55 PM, Les Hazlewood <lh...@apache.org> wrote:
> Philippe and Tamás,
>
> I think your ideas are great actually and the idea makes quite a lot
> of sense depending on the application's needs.
>
> I don't see why there couldn't be something like a TreePermission
> implementation in Shiro that people could choose to use if they
> wanted.  It would have to be designed very well to ensure it is
> flexible, but it's a very interesting idea.
>
> If anyone wants to give this a shot, please open a Jira issue to keep
> track of it and discuss it on the dev list.
>
> Great stuff!
>
> Les
>
> On Thu, Nov 11, 2010 at 1:21 PM, Philippe Laflamme <tw...@gmail.com> wrote:
>>
>> I did succeed in implementing my own Permission class and making my use-case
>> work, so thanks a lot for Shiro's flexibility. In that respect, it's really
>> nicely done. I did have to copy/paste some WildcardPermission code which I
>> would rather not. It may need some additional protected methods; I'll try to
>> make a patch.
>>
>> I realize now that "bubbling-up" permissions is not appropriate in all
>> situations. I'd like to get some input on how I can implement my use-case
>> with Shiro.
>>
>> The main issue I have is that in order to access finer-grained permissions,
>> I first need to test the coarser-grained ones. Using a file-system as an
>> analogy (/a/b/c): to reach the 'c' folder, I have to read 'a', 'b' first.
>> But I want to manage permissions at the "c" level, meaning I want to grant
>> access to "c" which would then imply access to "a" and "b".
>>
>> I now realize that some permissions shouldn't bubble up. For example, if I
>> grant write to 'c', I don't want that to mean write to 'b' and 'a' as well.
>> That said, I would want it to mean read 'b' and 'a' since the user would
>> need to "reach" 'c' in order to write to it.
>>
>> So in Shiro terms, I guess what I'm saying is:
>>
>> fs:read:a:b:c implies fs:read:a:b and fs:read:a
>> fs:write:a:b:c implies fs:read:a:b and fs:read:a
>> more generally
>> fs:*:a:b:c implies fs:read:a:b and fs:read:a
>>
>> The system would allow read on "parent" entities when you have any
>> permission on one of its child. It bubbles up, but "downgrades" the
>> permission.
>>
>> Obviously, this is very different from WildcardPermissions and is very
>> specific to my use-case...
>>
>> Any thoughts on this from anyone?
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5730302.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Question regarding WildcardPermission

Posted by Les Hazlewood <lh...@apache.org>.

Philippe and Tamás,

I think your ideas are great actually and the idea makes quite a lot
of sense depending on the application's needs.

I don't see why there couldn't be something like a TreePermission
implementation in Shiro that people could choose to use if they
wanted.  It would have to be designed very well to ensure it is
flexible, but it's a very interesting idea.

If anyone wants to give this a shot, please open a Jira issue to keep
track of it and discuss it on the dev list.

Great stuff!

Les

On Thu, Nov 11, 2010 at 1:21 PM, Philippe Laflamme <tw...@gmail.com> wrote:
>
> I did succeed in implementing my own Permission class and making my use-case
> work, so thanks a lot for Shiro's flexibility. In that respect, it's really
> nicely done. I did have to copy/paste some WildcardPermission code which I
> would rather not. It may need some additional protected methods; I'll try to
> make a patch.
>
> I realize now that "bubbling-up" permissions is not appropriate in all
> situations. I'd like to get some input on how I can implement my use-case
> with Shiro.
>
> The main issue I have is that in order to access finer-grained permissions,
> I first need to test the coarser-grained ones. Using a file-system as an
> analogy (/a/b/c): to reach the 'c' folder, I have to read 'a', 'b' first.
> But I want to manage permissions at the "c" level, meaning I want to grant
> access to "c" which would then imply access to "a" and "b".
>
> I now realize that some permissions shouldn't bubble up. For example, if I
> grant write to 'c', I don't want that to mean write to 'b' and 'a' as well.
> That said, I would want it to mean read 'b' and 'a' since the user would
> need to "reach" 'c' in order to write to it.
>
> So in Shiro terms, I guess what I'm saying is:
>
> fs:read:a:b:c implies fs:read:a:b and fs:read:a
> fs:write:a:b:c implies fs:read:a:b and fs:read:a
> more generally
> fs:*:a:b:c implies fs:read:a:b and fs:read:a
>
> The system would allow read on "parent" entities when you have any
> permission on one of its child. It bubbles up, but "downgrades" the
> permission.
>
> Obviously, this is very different from WildcardPermissions and is very
> specific to my use-case...
>
> Any thoughts on this from anyone?
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5730302.html
> Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Philippe Laflamme <tw...@gmail.com>.

I did succeed in implementing my own Permission class and making my use-case
work, so thanks a lot for Shiro's flexibility. In that respect, it's really
nicely done. I did have to copy/paste some WildcardPermission code which I
would rather not. It may need some additional protected methods; I'll try to
make a patch.

I realize now that "bubbling-up" permissions is not appropriate in all
situations. I'd like to get some input on how I can implement my use-case
with Shiro.

The main issue I have is that in order to access finer-grained permissions,
I first need to test the coarser-grained ones. Using a file-system as an
analogy (/a/b/c): to reach the 'c' folder, I have to read 'a', 'b' first.
But I want to manage permissions at the "c" level, meaning I want to grant
access to "c" which would then imply access to "a" and "b".

I now realize that some permissions shouldn't bubble up. For example, if I
grant write to 'c', I don't want that to mean write to 'b' and 'a' as well.
That said, I would want it to mean read 'b' and 'a' since the user would
need to "reach" 'c' in order to write to it.

So in Shiro terms, I guess what I'm saying is:

fs:read:a:b:c implies fs:read:a:b and fs:read:a
fs:write:a:b:c implies fs:read:a:b and fs:read:a
more generally
fs:*:a:b:c implies fs:read:a:b and fs:read:a

The system would allow read on "parent" entities when you have any
permission on one of its child. It bubbles up, but "downgrades" the
permission.

Obviously, this is very different from WildcardPermissions and is very
specific to my use-case...

Any thoughts on this from anyone?
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5730302.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Les Hazlewood <lh...@apache.org>.

I'll give an example of why the existing behavior makes sense to me:

user:read:jsmith:username

Just because I can read (view) the jsmith user's username does _not_ imply
that I should be able to see all of jsmith's user data.  Perhaps I shouldn't
be able to see the user record's password field for example.

Granted, this is just an example (and I'm not even advocating that you
format permission strings in this way - I would probably arrange the tokens
differently), but it is a fairly common one that illustrates why
WildcardPermission tokens usually start out more general and get more
specific as you go further down the permission string.

The large majority of use cases of the WildcardPermission assume this type
of behavior and this convention, so I don't know that it should be changed.
 But the beauty of the Permission interface is that you could change this
default logic slightly to meet your application's needs by creating your own
implementation, even using the WIldcardPermission's source code as the bases
for your (slightly different) implementation.

That's my .02 :)

Les

On Thu, Nov 11, 2010 at 7:15 AM, Philippe Laflamme <tw...@gmail.com>wrote:

>
>
> Brian Demers wrote:
> >
> > However in your case your saying a more specific permission grants access
> > to
> > a more general permission.  Maybe this is the part that I do not
> > understand.
> >
>
> Well that may depend on how Shiro behaves, but there's a subtlety here that
> is important.
>
> What I'm trying to express is that a more specific permission implies all
> lesser specific permissions "up" it's path. But the subtlety is that this
> does not GRANT these permissions, it implies them. The end result is not
> the
> same as if I had explicitly stated that the user had the lesser specific
> permission.
>
> An example will help.
>
> userA=thing:read:foo
> userB=thing:read:foo:bar
>
> Current situation:
> | User   | Permission | Permitted |
> | userA | thing:read:foo | true |
> | userA | thing:read:foo:bar | true |
> | userA | thing:read:foo:foobar | true |
> | userB | thing:read:foo | false |
> | userB | thing:read:foo:bar | true |
> | userB | thing:read:foo:foobar | false |
>
> My situation:
> | User   | Permission | Permitted |
> | userA | thing:read:foo | true |
> | userA | thing:read:foo:bar | true |
> | userA | thing:read:foo:foobar | true |
> | userB | thing:read:foo | true |
> | userB | thing:read:foo:bar | true |
> | userB | thing:read:foo:foobar | false |
>
> In my situatiuon, eventhough both userA and userB have "true" for
> permission
> "thing:read:foo", they don't have the same permission of other more
> specific
> permissions (foobar). This is the difference with granting and implying a
> permission.
>
> Imagine that we have TaskLists and Tasks inside them. My use-case is
> granting access to a specific Task from my TaskList to a friend, but
> without
> exposing the whole TaskList to my friend. My friend needs to see my
> TaskList
> to access the Task I gave him access to...
>
> Does this clarify things?
>
> Cheers,
> Philippe
>
> On Thu, Nov 11, 2010 at 9:34 AM, Philippe Laflamme
> <tw...@gmail.com>wrote:
>
> >
> > Hi,
> >
> > I've got a question regarding the current implementation of
> > WildcardPermission.
> >
> > Currently, the following holds true:
> >
> > thing:read:foo implies thing:read:foo:bar
> >
> > Which basically means that if you can "read" the "foo" "thing", you can
> > also
> > "read" the "bar" "thing" in the "foo" "thing".
> >
> > But the reverse statement does not hold true:
> >
> > thing:read:foo:bar does NOT imply thing:read:foo
> >
> > Meaning that if you can read "bar" you can't read "foo".
> >
> > Now, at first I thought that it made sense, but after thinking about it,
> I
> > can't figure out what's a valid use case for this.
> >
> > My reasoning is based on the fact that "bar" in this situation is
> > something
> > that belongs to "foo" (otherwise, I would have a separate permission
> > domain,
> > ie: otherthing:read:bar). So if "bar" only exists if "foo" also does,
> what
> > is the valid use case of allowing access to "bar" but not to "foo"?
> >
> > Note that saying that the "longer" permission implies the "shorter" DOES
> > NOT
> > imply other longer permissions. That is,
> >
> > thing:read:foo:bar implies thing:read:foo --> true
> > thing:read:foo:bar implies thing:read:foo:foobar --> false
> >
> > Is my reasoning valid?
> >
> > I've created my own Permission implementation that does exactly that and
> > it
> > behaves as expected (I can read foo, bar, but not foobar). I'm wondering
> > what is a valid use-case for NOT wanting this behaviour?
> >
> > Thanks!
> > Philippe
> > --
> > View this message in context:
> >
> http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5728829.html
> > Sent from the Shiro User mailing list archive at Nabble.com.
> >
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5729002.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Question regarding WildcardPermission

Posted by Philippe Laflamme <tw...@gmail.com>.


Brian Demers wrote:
> 
> However in your case your saying a more specific permission grants access
> to
> a more general permission.  Maybe this is the part that I do not
> understand.
> 

Well that may depend on how Shiro behaves, but there's a subtlety here that
is important.

What I'm trying to express is that a more specific permission implies all
lesser specific permissions "up" it's path. But the subtlety is that this
does not GRANT these permissions, it implies them. The end result is not the
same as if I had explicitly stated that the user had the lesser specific
permission.

An example will help.

userA=thing:read:foo
userB=thing:read:foo:bar

Current situation:
| User   | Permission | Permitted |
| userA | thing:read:foo | true |
| userA | thing:read:foo:bar | true |
| userA | thing:read:foo:foobar | true |
| userB | thing:read:foo | false |
| userB | thing:read:foo:bar | true |
| userB | thing:read:foo:foobar | false |

My situation:
| User   | Permission | Permitted |
| userA | thing:read:foo | true |
| userA | thing:read:foo:bar | true |
| userA | thing:read:foo:foobar | true |
| userB | thing:read:foo | true |
| userB | thing:read:foo:bar | true |
| userB | thing:read:foo:foobar | false |

In my situatiuon, eventhough both userA and userB have "true" for permission
"thing:read:foo", they don't have the same permission of other more specific
permissions (foobar). This is the difference with granting and implying a
permission.

Imagine that we have TaskLists and Tasks inside them. My use-case is
granting access to a specific Task from my TaskList to a friend, but without
exposing the whole TaskList to my friend. My friend needs to see my TaskList
to access the Task I gave him access to...

Does this clarify things?

Cheers,
Philippe

On Thu, Nov 11, 2010 at 9:34 AM, Philippe Laflamme
<tw...@gmail.com>wrote:

>
> Hi,
>
> I've got a question regarding the current implementation of
> WildcardPermission.
>
> Currently, the following holds true:
>
> thing:read:foo implies thing:read:foo:bar
>
> Which basically means that if you can "read" the "foo" "thing", you can
> also
> "read" the "bar" "thing" in the "foo" "thing".
>
> But the reverse statement does not hold true:
>
> thing:read:foo:bar does NOT imply thing:read:foo
>
> Meaning that if you can read "bar" you can't read "foo".
>
> Now, at first I thought that it made sense, but after thinking about it, I
> can't figure out what's a valid use case for this.
>
> My reasoning is based on the fact that "bar" in this situation is
> something
> that belongs to "foo" (otherwise, I would have a separate permission
> domain,
> ie: otherthing:read:bar). So if "bar" only exists if "foo" also does, what
> is the valid use case of allowing access to "bar" but not to "foo"?
>
> Note that saying that the "longer" permission implies the "shorter" DOES
> NOT
> imply other longer permissions. That is,
>
> thing:read:foo:bar implies thing:read:foo --> true
> thing:read:foo:bar implies thing:read:foo:foobar --> false
>
> Is my reasoning valid?
>
> I've created my own Permission implementation that does exactly that and
> it
> behaves as expected (I can read foo, bar, but not foobar). I'm wondering
> what is a valid use-case for NOT wanting this behaviour?
>
> Thanks!
> Philippe
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5728829.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>



-- 
View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5729002.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Question regarding WildcardPermission

Posted by Brian Demers <br...@gmail.com>.

I am not sure I follow, granted my perception of the WildcardPermission is
how I have used it.

I typically use something like: thing:foo:bar:read
 so I can use : thing:foo:*:read or thing:foo:*  which will be true for
permissions of thing:foo:bar:read, or thing:foo:read

However in your case your saying a more specific permission grants access to
a more general permission.  Maybe this is the part that I do not understand.





On Thu, Nov 11, 2010 at 9:34 AM, Philippe Laflamme <tw...@gmail.com>wrote:

>
> Hi,
>
> I've got a question regarding the current implementation of
> WildcardPermission.
>
> Currently, the following holds true:
>
> thing:read:foo implies thing:read:foo:bar
>
> Which basically means that if you can "read" the "foo" "thing", you can
> also
> "read" the "bar" "thing" in the "foo" "thing".
>
> But the reverse statement does not hold true:
>
> thing:read:foo:bar does NOT imply thing:read:foo
>
> Meaning that if you can read "bar" you can't read "foo".
>
> Now, at first I thought that it made sense, but after thinking about it, I
> can't figure out what's a valid use case for this.
>
> My reasoning is based on the fact that "bar" in this situation is something
> that belongs to "foo" (otherwise, I would have a separate permission
> domain,
> ie: otherthing:read:bar). So if "bar" only exists if "foo" also does, what
> is the valid use case of allowing access to "bar" but not to "foo"?
>
> Note that saying that the "longer" permission implies the "shorter" DOES
> NOT
> imply other longer permissions. That is,
>
> thing:read:foo:bar implies thing:read:foo --> true
> thing:read:foo:bar implies thing:read:foo:foobar --> false
>
> Is my reasoning valid?
>
> I've created my own Permission implementation that does exactly that and it
> behaves as expected (I can read foo, bar, but not foobar). I'm wondering
> what is a valid use-case for NOT wanting this behaviour?
>
> Thanks!
> Philippe
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5728829.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>