users@jax-rs-spec.java.net

[jax-rs-spec users] Re: A common way to enable _at_RolesAllowed

From: <markus_at_headcrashing.eu>
Date: Fri, 04 Mar 2016 00:18:34 +0100

That is exactly what I want, in both, Java SE and Java EE, and in the
same way for the application programmer.

Zitat von arjan tijms <arjan.tijms_at_gmail.com>:

> On Thu, Mar 3, 2016 at 11:30 PM, <markus_at_headcrashing.eu> wrote:
>
>> 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.
>
>
> Clear, and sounds good.
>
> In my opinion it should Just Work. Let the user put
> javax.annotation.security.RolesAllowed on a JAX-RS resource method, and
> that should be all for the user to do with respect to JAX-RS. No specific
> JAX-RS configuration should be needed to get JAX-RS to pick up/process this.
>
>
>
>
>
>>
>>
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>