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 <[email protected]> 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 <[email protected]> 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.
>
