Re: wicket-security Subject getPrincipals

[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