I evolved from that post a solution that guarantee less coupling on the
component side.
What is proposed is to have GroupedAware wicket component. I decided to have
a meta data called rule to extract from the component so I do not need my
component to extend or implement anything.
This is how to recover a specific rule to check against the Roles, and
complete the wicket part of the story
When you extract the Rule, and you have somewhere the collection of role,
you are done, as Lee said. You just check your Rule specific permission
against the Roles, looking up for the user specific Role that is written
some where in the rule.
This solution allows you to check against user system wide roles (like
admin, superuser, user, guest...) and also against resource specific role
(owner, edit, view...).
If you need just first type of roles, you can be fine with just shiro
facilities and ask account.canDo("xxx).
With second, you need some new entities. I am working on that, I jhave a
specific implementation I am generalizing these days.
I am calling that Relation for now, that is, well, the relation between an
account (a subject, generallly speaking) and a resource that user can
manipulate and is typical something of the application domain. This solution
will probably bring a couple of interface: Relation and UserResource that
applications will implement. A third interface should be Subject and is
basically the same concept already in shiro (and a lot of other security
package out there).
This allow me to cover a lot of use case with decoupled and generic
solution. I am working on this right now, to implement a web site that will
allow users to make some of their resources (uploaded images) private or
public with different kind of access. This is a perfect example of the
UserResource with a Relation to another account that I talked before.
A UserResource could be anything: an image but also a collection of images.
The Relation can be of any kind but in a typical application, you have some
fixed Role, that are, set of permission: owner can do anything, editor
anything but delete, viewer... and so on.
This are system defined role but can be applied to a specific user resource.
On Tue, Mar 16, 2010 at 4:33 AM, Fernando Wermus
<[email protected]>wrote:
> Les,
> Thanks for your post. I am newbie at this. I will make a try and if I
> can set up wicket I will post and example of it for sure. In this link
> http://osdir.com/ml/users-wicket.apache.org/2010-02/msg00533.html there is
> an extended explanation what I am looking for.
>
>
> On Sun, Mar 7, 2010 at 3:09 PM, Les Hazlewood <[email protected]>wrote:
>
>> Permissions exist to solve this problem. Think of roles as a named
>> collection of permissions - you can create and delete roles at any
>> time because your security policy is based around permission checks,
>> not role checks.
>>
>> Permissions exist to support fine-grained security models - roles are
>> usually too coarse-grained to handle dynamic policies.
>>
>> So, if you need a dynamic security model that can change at runtime,
>> create your system around the premise of permission checks: each
>> check is statically defined and reflects raw functionality that only
>> changes when your code/logic changes. You can assign permissions to
>> roles or groups at runtime as you see fit.
>>
>> The WildcardPermission JavaDoc does a good job of explaining how
>> permissions can be used for ultra-fine-grained control. Does this
>> help/make sense?
>>
>> Les
>>
>> 2010/3/4 Altuğ Bilgin Altıntaş <[email protected]>:
>> > Hi,
>> > Fernando is right.
>> > There is no concrete example or documentation about this concept
>> (dynamic
>> > roles). Am i right ?
>> > Thanks.
>> > 2010/3/4 Fernando Wermus <[email protected]>
>> >>
>> >> Hi all,
>> >> I am looking for using shiro with dynamic roles in site (wicket
>> one).
>> >> I would like to know if there is some example about this.
>> >> Also, I will explain what I understand for "dynamic roles" to avoid any
>> >> misunderstanding. For instance, a user has a role ADMIN on object A,
>> but a
>> >> role USER on object B. This can change passing the time.
>> >> thanks in advance.
>> >> --
>> >> Fernando Wermus.
>> >>
>> >> www.linkedin.com/in/fernandowermus
>> >
>> >
>> >
>> > --
>> > Altuğ.
>> >
>>
>
>
>
> --
> Fernando Wermus.
>
> www.linkedin.com/in/fernandowermus
>
--
Daniele Dellafiore
http://danieledellafiore.net
