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 <arjan.tijms_at_gmail.com>:
> 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, <markus_at_headcrashing.eu> 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 <arjan.tijms_at_gmail.com>:
>>
>>
>> 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
>>>>
>>>>
>>>>
>>
>>
>>