> On 03.03.2016, at 23:40, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> 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.
+1 for this. @RolesAllowed should work out-of-the-box.
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
workshops.adam-bien.com
effectivejavaee.com
blog.adam-bien.com
airhacks.news
Author of:
"Real World Java EE Night Hacks”,
"Real World Java EE Patterns— Rethinking Best Practices"