[jax-rs-spec users] Re: A common way to enable _at_RolesAllowed

From: <>
Date: Tue, 01 Mar 2016 23:12:51 +0100

The JAX-RS specification says that JAX-RS can be used not only within
Java EE but also as a standalone technology ontop of Java SE. To make
a JAX-RS application work correctly in both environments (hence:
without JSR 375 beneath) the JAX-RS specification either must declare
that JSR 375 is to be bundled with JAX-RS on Java SE, or it must
define a different way to declare security with in turn enables JSR
375 on Java EE but may use any other technology on Java SE.

Zitat von arjan tijms <>:

> If it's an Interceptor spec interceptor, will it not run regardless of what
> the JAX-RS spec otherwise says about security?
> On Tue, Mar 1, 2016 at 10:31 PM, <> wrote:
>> To clarify my proposal, I actually don't care about *which* annotation is
>> getting used, as long as JAX-RS 2.1 specifies one common solution for ALL
>> implementations. Certainly my vote would be for "enable @RolesAllowed by
>> default" as it is what currently everone simply would expect to work out of
>> the box.
>> Zitat von arjan tijms <>:
>> 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, <> 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