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
