Resource authorisation scenario: dealing with non-application wide permissions

[Daniele Dellafiore <il...@gmail.com>]

Hi.

Imagine this scenario: a webapp that allows creation of groups of people.
There is the owner, the administrator and the normal user for every group.
Like google groups, yahoo groups, facebook groups, a chat... a lot of
examples :)

If we define permission as string concatenation, I can have "group:delete"
as permission.
In this scenario the permission is not application wide, but "group
specific". Is related to the entity of my domain: Group.

Unfortunately I have no idea how to solve my problem in AuthStrategy, where
I can just access the user, not his particular Role in the specific group of
my webapp, I do not have enough information. I can't know in
isActionAuthorized method what is the group to ask authorization access for
"group.delete" permission.
If I know which is the group (domain entity) I can ask the user for the role
he has in the group, and see if it's role has "group.delete" permission.
Or any similar implementation, the point is that I miss an information.

What can be a nice way to solve this problem with Wicket
AuthorizationStrategy?

I have just read a recent article about how to integrate shiro and wicket:
http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html

My point with that solution is that as far as I know, overriding isVisible()
is a discouraged practice. More over, the visibility control for
authorisation access has better room in the AuthorizationStrategy and if I
remember fine, what change is the isVisibilityAllowed().

I can just figure out to to put that information (the role of the subject in
the group) in the Action, but I have to learn how. Do you think should be a
nice idea? Or maybe I am making my life harder for nothing and setting
visibilityAllowed (or even override that method) would be fine enough?

I think I can save a lot of "ifs" or a lot of override if I Can figure out a
way to implement it the way I described.

I will sleep on this :)

-- 
Daniele Dellafiore
http://danieledellafiore.net

Re: Resource authorisation scenario: dealing with non-application wide permissions

[Igor Vaynberg <ig...@gmail.com>]

your components are the ones that carry context, so...

boolean isActionAuthorized(Component component, Action action) {
    if (component instanceof GroupAware) {
        Group group=((GroupAware)component).getGroup();
        ...

-igor


On Thu, Feb 11, 2010 at 5:50 PM, Daniele Dellafiore <il...@gmail.com> wrote:
> Hi.
>
> Imagine this scenario: a webapp that allows creation of groups of people.
> There is the owner, the administrator and the normal user for every group.
> Like google groups, yahoo groups, facebook groups, a chat... a lot of
> examples :)
>
> If we define permission as string concatenation, I can have "group:delete"
> as permission.
> In this scenario the permission is not application wide, but "group
> specific". Is related to the entity of my domain: Group.
>
> Unfortunately I have no idea how to solve my problem in AuthStrategy, where
> I can just access the user, not his particular Role in the specific group of
> my webapp, I do not have enough information. I can't know in
> isActionAuthorized method what is the group to ask authorization access for
> "group.delete" permission.
> If I know which is the group (domain entity) I can ask the user for the role
> he has in the group, and see if it's role has "group.delete" permission.
> Or any similar implementation, the point is that I miss an information.
>
> What can be a nice way to solve this problem with Wicket
> AuthorizationStrategy?
>
> I have just read a recent article about how to integrate shiro and wicket:
> http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html
>
> My point with that solution is that as far as I know, overriding isVisible()
> is a discouraged practice. More over, the visibility control for
> authorisation access has better room in the AuthorizationStrategy and if I
> remember fine, what change is the isVisibilityAllowed().
>
> I can just figure out to to put that information (the role of the subject in
> the group) in the Action, but I have to learn how. Do you think should be a
> nice idea? Or maybe I am making my life harder for nothing and setting
> visibilityAllowed (or even override that method) would be fine enough?
>
> I think I can save a lot of "ifs" or a lot of override if I Can figure out a
> way to implement it the way I described.
>
> I will sleep on this :)
>
> --
> Daniele Dellafiore
> http://danieledellafiore.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Resource authorisation scenario: dealing with non-application wide permissions

[Fernando Wermus <fe...@gmail.com>]

Danielle,
     I run out into the same problem. Did you solve it? if so, how?

thanks in advance

On Thu, Feb 11, 2010 at 11:50 PM, Daniele Dellafiore <il...@gmail.com>wrote:

> Hi.
>
> Imagine this scenario: a webapp that allows creation of groups of people.
> There is the owner, the administrator and the normal user for every group.
> Like google groups, yahoo groups, facebook groups, a chat... a lot of
> examples :)
>
> If we define permission as string concatenation, I can have "group:delete"
> as permission.
> In this scenario the permission is not application wide, but "group
> specific". Is related to the entity of my domain: Group.
>
> Unfortunately I have no idea how to solve my problem in AuthStrategy, where
> I can just access the user, not his particular Role in the specific group
> of
> my webapp, I do not have enough information. I can't know in
> isActionAuthorized method what is the group to ask authorization access for
> "group.delete" permission.
> If I know which is the group (domain entity) I can ask the user for the
> role
> he has in the group, and see if it's role has "group.delete" permission.
> Or any similar implementation, the point is that I miss an information.
>
> What can be a nice way to solve this problem with Wicket
> AuthorizationStrategy?
>
> I have just read a recent article about how to integrate shiro and wicket:
> http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html
>
> My point with that solution is that as far as I know, overriding
> isVisible()
> is a discouraged practice. More over, the visibility control for
> authorisation access has better room in the AuthorizationStrategy and if I
> remember fine, what change is the isVisibilityAllowed().
>
> I can just figure out to to put that information (the role of the subject
> in
> the group) in the Action, but I have to learn how. Do you think should be a
> nice idea? Or maybe I am making my life harder for nothing and setting
> visibilityAllowed (or even override that method) would be fine enough?
>
> I think I can save a lot of "ifs" or a lot of override if I Can figure out
> a
> way to implement it the way I described.
>
> I will sleep on this :)
>
> --
> Daniele Dellafiore
> http://danieledellafiore.net
>



-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus