You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Emond Papegaaij <em...@topicus.nl> on 2010/09/01 14:30:36 UTC
{Spam?} Re: wicket-security Subject getPrincipals
Hi Thibault,
I do agree with you that the Subject interface is not very clean. However it
is not the interface that is incompatible with your needs, but the way Wicket
Security works. If you look at that interface, it also has a method
'setReadOnly()', which, as documented, will always be called on subjects being
handed to the security layer (on logon). A subject is not allowed to change
its principals after that, making it impossible to implement dynamically
changing authorizations.
The reason for this can be found in SimpleCachingHive, which caches
permissions for subjects. Without this cache, Wicket Security would be way too
slow to use in a large application.
Supporting dynamic authorization would be a nice feature to support, but will
require major changes to Wicket Security. Especially caching of permission
lookups will be difficult to implement.
I still plan on doing some work on Wicket Security for Wicket 1.5, which
should see some API improvements. However, my time is very limited at the
moment. A release for 1.4, which fixes some minor bugs, is also on my todo
list.
Best regards,
Emond Papegaaij
On Monday 23 August 2010 13:30:41 Thibault Kruse wrote:
> Hi, combining Shiro with WASP, I found that the interface
> org.apache.wicket.security.hive.authentication.Subject
> requires a method
>
> /**
> * A readonly view of the principals.
> *
> * @return the principals
> */
> public Set<Principal> getPrincipals();
>
> the only usage for that I found is in BasicHive
> subjectPrincipals = subject.getPrincipals();
> for (Principal curPrincipal : principalSet)
> {
> if
> (subjectPrincipals.contains(curPrincipal) ||
> curPrincipal.implies(subject))
> return true;
> }
>
> My minor problem with that is that it exposes the Principals of the
> Subject needlessly to the rest of the world. Which is bad if the rest of
> the world decides to cache the principals, and they change in the
> meantime, as Shiro would allow.
>
> To improve, the above could be changed to require
> public boolean Subject.principalsImply(Principal);
> leaving it to the Subject implementation to verify, not exposing actual
> Principals. As this would be sufficient for all cureent needs I can think
> of and see, having a getter function for Principal exposes more than we
> need to expose. Should caching be required that can surely be the
> responsibility of the Subject (or the underlying framework used by the
> subject).
>
> As an example the LoginContainer$MultiSubject
> already "caches" the principals reading them only in the constructor,
> making that incompatible with the Shiro Strategy of dynamically changing
> authorizations.
>
> regards,
> Thibault
Re: wicket-security Subject getPrincipals
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Les,
I thought about this, and I don't think it the way to go for Wicket Security.
Wicket Security provides very good integration with Wicket on all levels of
the API, much better than Shiro can ever provide. With the upcomming changes
for 1.5, which will include annotations on components to define permissions,
this integration will improve even further.
For Wicket Security, there is no need to reinvent the wheel, because Wicket
Security is already working. Very little changes are needed to the security
layer itself. For people who want to use Shiro with Wicket, there is a project
wicket-shiro, which does that.
Also, rewriting Wicket Security to use Apache Shiro will force all users of
Wicket Security to rewrite major parts of their application; something I
really don't want.
Best regards,
Emond Papegaaij
On Wednesday 01 September 2010 18:10:13 Les Hazlewood wrote:
> Hi Edmond,
>
> Have you thought of using Apache Shiro as the basis for Wicket
> Security? Much like SLF4J, Shiro has a general purpose application
> security API and then it has its default implementation. It could
> even be implemented with JAAS or Spring Security or other mechanisms.
>
> Shiro already supports robust caching strategies, events, a highly
> pluggable architecture and more - and it of course allows dynamic
> changes at runtime.
>
> It seems like quite an awful lot of work to 'reinvent the wheel' for a
> security API - for example, we don't create our own logging APIs for
> each project we work on. And after working on Shiro for ~ 6 years
> now, trust me, it is no small effort to 'get it right' when building a
> security API :). Just a thought...
>
> Cheers,
>
> Les
>
> P.S. I know Shiro's incubation status might deter some people from
> using it, but not to worry - it will become a Top Level Project at
> this month's Apache Board meeting (barring any objections by the
> board, of course). We'll release 1.1 shortly thereafter.
>
> On Wed, Sep 1, 2010 at 5:30 AM, Emond Papegaaij
>
> <em...@topicus.nl> wrote:
> > Hi Thibault,
> >
> > I do agree with you that the Subject interface is not very clean. However
> > it is not the interface that is incompatible with your needs, but the
> > way Wicket Security works. If you look at that interface, it also has a
> > method 'setReadOnly()', which, as documented, will always be called on
> > subjects being handed to the security layer (on logon). A subject is not
> > allowed to change its principals after that, making it impossible to
> > implement dynamically changing authorizations.
> >
> > The reason for this can be found in SimpleCachingHive, which caches
> > permissions for subjects. Without this cache, Wicket Security would be
> > way too slow to use in a large application.
> >
> > Supporting dynamic authorization would be a nice feature to support, but
> > will require major changes to Wicket Security. Especially caching of
> > permission lookups will be difficult to implement.
> >
> > I still plan on doing some work on Wicket Security for Wicket 1.5, which
> > should see some API improvements. However, my time is very limited at the
> > moment. A release for 1.4, which fixes some minor bugs, is also on my
> > todo list.
> >
> > Best regards,
> > Emond Papegaaij
> >
> > On Monday 23 August 2010 13:30:41 Thibault Kruse wrote:
> >> Hi, combining Shiro with WASP, I found that the interface
> >> org.apache.wicket.security.hive.authentication.Subject
> >> requires a method
> >>
> >> /**
> >> * A readonly view of the principals.
> >> *
> >> * @return the principals
> >> */
> >> public Set<Principal> getPrincipals();
> >>
> >> the only usage for that I found is in BasicHive
> >> subjectPrincipals = subject.getPrincipals();
> >> for (Principal curPrincipal : principalSet)
> >> {
> >> if
> >> (subjectPrincipals.contains(curPrincipal) ||
> >> curPrincipal.implies(subject))
> >> return true;
> >> }
> >>
> >> My minor problem with that is that it exposes the Principals of the
> >> Subject needlessly to the rest of the world. Which is bad if the rest of
> >> the world decides to cache the principals, and they change in the
> >> meantime, as Shiro would allow.
> >>
> >> To improve, the above could be changed to require
> >> public boolean Subject.principalsImply(Principal);
> >> leaving it to the Subject implementation to verify, not exposing actual
> >> Principals. As this would be sufficient for all cureent needs I can
> >> think of and see, having a getter function for Principal exposes more
> >> than we need to expose. Should caching be required that can surely be
> >> the responsibility of the Subject (or the underlying framework used by
> >> the subject).
> >>
> >> As an example the LoginContainer$MultiSubject
> >> already "caches" the principals reading them only in the constructor,
> >> making that incompatible with the Shiro Strategy of dynamically changing
> >> authorizations.
> >>
> >> regards,
> >> Thibault
Re: {Spam?} Re: wicket-security Subject getPrincipals
Posted by Les Hazlewood <lh...@apache.org>.
Hi Edmond,
Have you thought of using Apache Shiro as the basis for Wicket
Security? Much like SLF4J, Shiro has a general purpose application
security API and then it has its default implementation. It could
even be implemented with JAAS or Spring Security or other mechanisms.
Shiro already supports robust caching strategies, events, a highly
pluggable architecture and more - and it of course allows dynamic
changes at runtime.
It seems like quite an awful lot of work to 'reinvent the wheel' for a
security API - for example, we don't create our own logging APIs for
each project we work on. And after working on Shiro for ~ 6 years
now, trust me, it is no small effort to 'get it right' when building a
security API :). Just a thought...
Cheers,
Les
P.S. I know Shiro's incubation status might deter some people from
using it, but not to worry - it will become a Top Level Project at
this month's Apache Board meeting (barring any objections by the
board, of course). We'll release 1.1 shortly thereafter.
On Wed, Sep 1, 2010 at 5:30 AM, Emond Papegaaij
<em...@topicus.nl> wrote:
> Hi Thibault,
>
> I do agree with you that the Subject interface is not very clean. However it
> is not the interface that is incompatible with your needs, but the way Wicket
> Security works. If you look at that interface, it also has a method
> 'setReadOnly()', which, as documented, will always be called on subjects being
> handed to the security layer (on logon). A subject is not allowed to change
> its principals after that, making it impossible to implement dynamically
> changing authorizations.
>
> The reason for this can be found in SimpleCachingHive, which caches
> permissions for subjects. Without this cache, Wicket Security would be way too
> slow to use in a large application.
>
> Supporting dynamic authorization would be a nice feature to support, but will
> require major changes to Wicket Security. Especially caching of permission
> lookups will be difficult to implement.
>
> I still plan on doing some work on Wicket Security for Wicket 1.5, which
> should see some API improvements. However, my time is very limited at the
> moment. A release for 1.4, which fixes some minor bugs, is also on my todo
> list.
>
> Best regards,
> Emond Papegaaij
>
> On Monday 23 August 2010 13:30:41 Thibault Kruse wrote:
>> Hi, combining Shiro with WASP, I found that the interface
>> org.apache.wicket.security.hive.authentication.Subject
>> requires a method
>>
>> /**
>> * A readonly view of the principals.
>> *
>> * @return the principals
>> */
>> public Set<Principal> getPrincipals();
>>
>> the only usage for that I found is in BasicHive
>> subjectPrincipals = subject.getPrincipals();
>> for (Principal curPrincipal : principalSet)
>> {
>> if
>> (subjectPrincipals.contains(curPrincipal) ||
>> curPrincipal.implies(subject))
>> return true;
>> }
>>
>> My minor problem with that is that it exposes the Principals of the
>> Subject needlessly to the rest of the world. Which is bad if the rest of
>> the world decides to cache the principals, and they change in the
>> meantime, as Shiro would allow.
>>
>> To improve, the above could be changed to require
>> public boolean Subject.principalsImply(Principal);
>> leaving it to the Subject implementation to verify, not exposing actual
>> Principals. As this would be sufficient for all cureent needs I can think
>> of and see, having a getter function for Principal exposes more than we
>> need to expose. Should caching be required that can surely be the
>> responsibility of the Subject (or the underlying framework used by the
>> subject).
>>
>> As an example the LoginContainer$MultiSubject
>> already "caches" the principals reading them only in the constructor,
>> making that incompatible with the Shiro Strategy of dynamically changing
>> authorizations.
>>
>> regards,
>> Thibault
>