Hi,
On Thu, Mar 3, 2016 at 6:35 PM, <markus_at_headcrashing.eu> wrote:
> What configuration does actually prevent WebSphere from supporting it by
> default?
>
In WebSphere (and Liberty) you always need to configure a so-called user
registry in IBM's own server.xml.
Then you need to set the authentication mechanism using either web.xml's
login-config -> auth-method, OR programmatically
using javax.security.auth.message.config.AuthConfigFactory.
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?
>
For the match and asking the user to authenticate JAX-RS can simply rely on
the existing security machinery. Upon encountering the common annotations'
@RolesAllowed all it has to do is check HttpServletRequest#isUserInRole for
each role in the @RolesAllowed annotation (any role satisfies the
constraint).
If the user is not authenticated at all
(HttpServletRequest#getUserPrincipal returns null), JAX-RS can call
HttpServletRequest#authenticate, which will trigger whatever authentication
mechanism the user has configured.
In fact, if I'm not mistaken HttpServletRequest#authenticate was
specifically added in Servlet 3.0 so a technology like JAX-RS could use it
to implement @RolesAllowed. It's a little strange that this was not adopted
earlier.
There's no need for JAX-RS to enable specifically BASIC AUTH. There's no
API available to enable the Servlet one, and for JAX-RS to ship with its
own authentication mechanism that implements BASIC AUTH and registering it
with the AuthConfigFactory is not really what JAX-RS should do I think.
Using the existing APIs @RolesAllowed support can be implemented with just
a few lines of code in a fully portable way. It's up to the user of course
to define (and if needed map) the actual roles and the backing identity
store and what have you.
Kind regards,
Arjan Tijms
>
> 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
>>>>
>>>>
>>>
>
>
>