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.
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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com