Again, to make clear my proposal: I do not want to enforce that
@RolesAllowed must be able find a matching user. I only say that
JAX-RS 2.1 must RESPECT its existence, which means that it shall
simply reject the invocation in case WebSphere is not configured
correctly.
As I said before, ALL JAX-RS implementations already are ABLE to
respect @RolesAllowed in that sense, and I just want to get rid of the
different solutions to ENABLE the taking-respect. I do NOT want JAX-RS
to come up with a solution how to authenticate users against a backend
etc.
Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
> 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
>>>>>
>>>>>
>>>>
>>
>>
>>