Hi all,
I suggest a breaking change to wicketstuff-shiro here:
https://github.com/wicketstuff/core/issues/328
In brief: wicketstuffshiro allows to use @ShiroSecurityConstraint or
@ShiroSecurityConstraints (with s at the end) annotations on Component
classes to trigger security checks at different phases like
initialization and on rendering. Currently subclass annotations
*discard* superclass annotations, and I suggest all annotation
constraints should be *merged* instead, as default.
A Component may have it's own @ShiroSecurityConstraint, but may also
have a superclass declaring security constraints using
@ShiroSecurityConstraint. Where it uses the same annotation as the
superclass, the superclass annotation is *discarded*.
As an example, the superclass might make sure that an abstract
wicketpage requires Authentication, and a the page subclass might
require a permission "product:details:view". In that case, the current
semantics would be that the subclass does not require authentication
anymore, because the parent annotation was overwritten.
I believe the current semantics cause surprise and may cause security
gaps due to bad assumptions by developers. I suggest making a breaking
change such that all superclass constraints are also checked by
default.
Martin Grigorov suggests to also allow overriding parent constraints,
just in order not to restrict developers. I somehow believe that would
be very bad security practice (a page showing security-sensible
details having a constraint, a subpage showing the same details having
less constraints), but still someone might find a good usecase for
this.
As a sidenote, the current semantics are also inconsistent because an
@ShiroSecurityConstraint annotation in a subclass will be merged with
an @ShiroSecurityConstraints (plural) in a parent class. So I believe
the current semantics have to be changed anyways.
Opinions?
cheers,
Thibault
I suggest a breaking change to wicketstuff-shiro here:
https://github.com/wicketstuff/core/issues/328
In brief: wicketstuffshiro allows to use @ShiroSecurityConstraint or
@ShiroSecurityConstraints (with s at the end) annotations on Component
classes to trigger security checks at different phases like
initialization and on rendering. Currently subclass annotations
*discard* superclass annotations, and I suggest all annotation
constraints should be *merged* instead, as default.
A Component may have it's own @ShiroSecurityConstraint, but may also
have a superclass declaring security constraints using
@ShiroSecurityConstraint. Where it uses the same annotation as the
superclass, the superclass annotation is *discarded*.
As an example, the superclass might make sure that an abstract
wicketpage requires Authentication, and a the page subclass might
require a permission "product:details:view". In that case, the current
semantics would be that the subclass does not require authentication
anymore, because the parent annotation was overwritten.
I believe the current semantics cause surprise and may cause security
gaps due to bad assumptions by developers. I suggest making a breaking
change such that all superclass constraints are also checked by
default.
Martin Grigorov suggests to also allow overriding parent constraints,
just in order not to restrict developers. I somehow believe that would
be very bad security practice (a page showing security-sensible
details having a constraint, a subpage showing the same details having
less constraints), but still someone might find a good usecase for
this.
As a sidenote, the current semantics are also inconsistent because an
@ShiroSecurityConstraint annotation in a subclass will be merged with
an @ShiroSecurityConstraints (plural) in a parent class. So I believe
the current semantics have to be changed anyways.
Opinions?
cheers,
Thibault