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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>
>
>