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
>>>
>>>
>>>
>
>
>