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