Hi,
On Tue, Mar 1, 2016 at 6:47 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> FYI globally enabling these and more security annotations for all Java EE
> components was supposed to be done in the Java EE Security JSR. Now that
> being said whether that work will actually happen in time is anyone's guess
Indeed, JSR 375 too is not moving as fast as I'd hoped it would. Still
struggling to get the basics done, and after that it's on to the often
discussed SecurityContext and who knows how much time we have for the
interceptors. Talking to the other specs to align in some way... may proof
to be challenging.
> - so I definitely think individual JSRs should take this on for now. I
> sure wish the CDI 2 EG would :-).
>
> > On Mar 1, 2016, at 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
> >
>