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