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 <sberyozkin_at_talend.com>:
> 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
>
> https://issues.apache.org/jira/browse/CXF-6817
>
> 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, 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
>>>
>>