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

From: <>
Date: Wed, 02 Mar 2016 19:58:34 +0100

May I interpret you answer as "Yes, JAX-RS 2.1 MUST specify a common
way to enable @RolesAllowed, and CXF will implement it ASAP"?

Zitat von Sergey Beryozkin <>:

> 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