It would be great to get a comment from the spec leads, as I think it
would be more or less simple to add it to JAX-RS 2.1 spec.
Zitat von Bill Burke <bburke_at_redhat.com>:
> I'm wondering if it should just be required to support OOTB. Again
> though, we need specify what, if anything needs to be in web.xml and
> what addition annotations JAX-RS needs. Its more than just
> @RolesAllowed, IMO.
>
> On 3/2/2016 1:58 PM, markus_at_headcrashing.eu wrote:
>>
>> 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
>>>>>
>>>>
>>
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com