I will agree we need define some standard Client APIs to support Basic
Auth. Currently customer can only do this via creating related http
headers manually.
Markus's suggestion is to make @RolesAllowd be supported via a standard
way. In my point of view, this part need configuration in web.xml or
server configuration file at least in WebSphere. So I do not think we can
provide a standard support way in jaxrs.
Thanks & Best Regards,
------------------------------------------------------------------------------
Iris Ding (¶¡ÉÙ¾ý Ding Shao jun)
WebSphere WebServices Development
Phone: 86 - 10 - 82453192
Tie line: 9053192
IBM China Software Development Laboratory (CSDL)
Address:Diamond Bld, ZGC SW Park, #8 Dongbeiwang Rd W, Shangdi, Beijing,
100193, China
------------------------------------------------------------------------------
From: Sergey Beryozkin <sberyozkin_at_talend.com>
To: <jsr370-experts_at_jax-rs-spec.java.net>
Date: 2016/03/03 05:12
Subject: Re: A common way to enable @RolesAllowed
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
>>
>