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

From: Sergey Beryozkin <>
Date: Wed, 2 Mar 2016 16:30:56 +0000

On 01/03/16 18:11, Bill Burke wrote:
> I'd like to see some clarification on this too. If your jax-rs
> service is an EJB, I believe the spec says @RolesAllowed is supposed
> to be honoured, but JAX-RS has no other annotations to define things
> like transport requirements (Is SSL required), nor does it define a
> way to specify an authentication protocol (BASIC, FORM, CERT, SAML,
> OIDC, etc.). So, you end up still having to define security
> constraints and login config within web.xml.
> Security is very undefined on the client. There's no standard way of
> doing BASIC auth. BASIC auth still seems to be used even though OAuth
> and other token based architectures are starting to be prevelant.
The users start driving it :-), opened few minutes ago

The only standard way I know of is to create an Authorization header
manually and set it on the target

Cheers, Sergey

> On 3/1/2016 12: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