>What do you think?
As we're streamlining security for the entire platform via JSR 375, I would
not be a fan of having another JAX-RS (or any spec for that matter)
specific annotation or other artefact to deal with security.
One of the plans for JSR 375 is to have an Interceptor spec/CDI based
@RolesAllowed equivalent, which may be more consistent, especially if
JAX-RS also further aligns with CDI.
For the existing common annotations version of @RolesAllowed I would
definitely go for "Enable it by default.". These things should Just Work,
and not require any "activation" really (some EJB containers had the same
problem, a need to activate @RolesAllowed, really inconvenient and hurting
portability of apps).
Kind regards,
Arjan Tijms
On Tue, Mar 1, 2016 at 6:28 PM, <markus_at_headcrashing.eu> wrote:
> Experts,
>
> I hope you're in the mood for another small spec clarification in the hope
> to further align Jersey, WebSphere, CXF and RestEasy. :-)
>
> The current Jersey manual says that it will respect role-based security
> annotations (@PermitAll, @DenyAll, @RolesAllowd; according to JSR 250
> "Common Annotations for the Java Platform") as soon as a Jersey-specific
> filter is EXPLICITLY enabled by means of JAX-RS feature config API. If I
> understood the WebSphere manual correctly, I respects these annotations BY
> DEFAULT. According chapter 36 of its manual, it seems as if RESTeasy wants
> EXPLICIT enabling by Servlet web.xml. CXF on the other hand apparantly
> wants the deployer to enable an interceptor EXPLICITLY. So all those JAX-RS
> products process these annotations, but each has a different way to enable
> it. Looking through the eyes of an ISV, this is real pain-in-the-* since
> security is a must-have in all non-trivial products and nobody wants to
> provide four different configs for the same off-the-shelf app.
>
> I'd like to suggest that the spec 2.1 defines ONE COMMON way which enables
> security on ALL JAX-RS products.
>
> I have two proposals:
>
> (a) Enable it by default. It should not do any real harm regarding
> backwards compatibility. This way, nobody has to worry about security
> besides adding above role annotations.
>
> (b) Enable it explicitly by adding @Secured on the Application class. I
> think this is ugly as the existence of above annotations already imply that
> security is wanted.
>
> As all products already support the functionality, we just need to agree
> upon a SINGLE way to enable it. I think people simply expect this in 2.1.
>
> What do you think?
>
> -Markus
>
>