MP 1.2 javaee7:javax.annotation.security dependency issue

12 views
Skip to first unread message

sst...@redhat.com

unread,
Aug 8, 2017, 4:11:41 PM8/8/17
to Eclipse MicroProfile
So I was just assuming that the JAX-RS spec defined the use of the common javaee7:javax.annotation.security package annotations like @RolesAllowed that we are using in the MP-JWT TCK to avoid a need for a web.xml descriptor, but it does not. So enabling this is a vendor specific step, and the general way of doing this via a JAX-RS interceptor is a hack. It does not in general properly integrate with a servlet based container when it comes to role mapping, propagation of authenticated identity, and security manager issues because it was not specified to do so. We were also having a discussion about pulling in the servlet security annotations like HttpConstraint, HttpMethodConstraint to be able to deal with transport guarantees, which is another area that JAX-RS says nothing about.

This is a general problem that we will continue to run into as we start integrating cross cutting concerns like security, logging, transactions, ...

The Java EE specs delegate concerns, and cherry picking APIs and mixing them together pushes a non-spec behavior into the JAX-RS provider implementation. We will have to define this in order to be able to build portable MP application deployments that don't require a ton of vendor specific configuration to achieve interoperability. 

As it stands now for the MP 1.2 release and it's inclusion of the JWT 1.0 release, we need to define that this also requires use of the javaee7:javax.annotation.security package annotations, and JAX-RS providers need a way of enabling security integration with the underlying container to support this. I don't see that we have time to do this in any portable way for the current timelines, so it will fall under the usual catch all of an implementation detail.

One way to address this, that we also don't have time for in a 1.0 release is to rely on the Config spec and build a common view of metadata for these non-spec usages so that implementations can map to the best way to manifest a set of given behaviors for the underlying container technology.

John D. Ament

unread,
Aug 8, 2017, 5:18:58 PM8/8/17
to Eclipse MicroProfile
I would be in favor of something using the Config spec.  I have no issue relying on the javax.annotation.security though.

John
Reply all
Reply to author
Forward
0 new messages