users@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 3 Mar 2016 20:24:21 -0500

Excellent, that's what we need. BTW, why would you ever specify username
password in an annotation? That is just bizarre.

On 3/3/2016 5:24 PM, arjan tijms wrote:
> On Thu, Mar 3, 2016 at 10:40 PM, Bill Burke <bburke_at_redhat.com
> <mailto:bburke_at_redhat.com>> wrote:
>
> @RolesAllowed should just be required to support. But, I stress
> again, @RolesAllowed is just half of the problem...
>
>
> I take it you're referring to this here:
>
> 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.
>
>
> Since JAX-RS is layered on top of Servlets, I'm eager to learn why
> defining the authentication mechanism in web.xml would presumably not
> be good enough.
>
> Note that there's also a programmatic variant to register an
> equivalent to what you can specify in web.xml via
> the AuthConfigFactory. In JSR 375 we're adding another variant of that
> based on CDI and annotations.
>
> For an example see here:
> https://github.com/javaee-security-spec/soteria/blob/master/test/app-mem-basic/src/main/java/test/Servlet.java#L17
>
> These work quite well with JAX-RS. For an earlier prototype see e.g.
> this article:
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>
> We're using something quite close to that in practice for the API of
> zeef.com <http://zeef.com>.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> BTW, IMO, the NIO and SSE stuff is borderline a waste of effort
> both for the spec lead and for us implementers that have to suffer
> the TCK. I just don't think you'll have a lot of people using
> either feature... Let the flames begin.
>
>
> On 3/3/2016 12:39 PM, markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu> wrote:
>
> As time is scarce and manpower is not for free, my proposal
> was to simply define a default API for the implementations we
> actually have in the products already. It would make ISVs
> lives much easier if we don't have to add container-specific
> enablers.
>
> Zitat von Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>>:
>
> Markus, I was only referring to Bill's idea that it would
> be good to have some standard way to do Basic Auth/etc.
> I'm not sure how far/if at all we can go about supporting
> @RolesAllowed in 2.1 - there are pieces of work to be done
> around the proposed NIO/etc API improvements (proposed by
> the spec leads), minor items proposed by us, and here I'd
> indeed support having something standard, loosely typed
> authentication API introduced given that indeed Basic Auth
> is only one of several options these days.
>
> @RolesAllowed is similar to Basic Auth, it is kind of
> outdated really, and other forms of the access control
> should be taken into the consideration, it was proposed by
> one of experts/users before that @Scopes (OAuth2 access
> token related) get introduced, etc.
>
> Sergey
> On 02/03/16 18:58, markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu> wrote:
>
>
> May I interpret you answer as "Yes, JAX-RS 2.1 MUST
> specify a common way to enable @RolesAllowed, and CXF
> will implement it ASAP"?
>
> Zitat von Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>>:
>
> 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
> <mailto: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
>
>
>
>
>
>
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com