What configuration does actually prevent WebSphere from supporting it
by default?
If @RolesAllowed is found, then simply enable BASIC AUTH and try to
match a role. If the match fails because the config in WebSphere is
incomplete, no access is granted. Where's the problem?
Zitat von Shao Jun Ding <dingsj_at_cn.ibm.com>:
> 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.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> From: Shao Jun Ding/China/IBM_at_IBMCN
> To: jsr370-experts_at_jax-rs-spec.java.net
> Date: 2016/03/03 09:28
> Subject: Re: A common way to enable @RolesAllowed
>
>
>
> 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
>>>
>>