[JAX_RS_SPEC-304] Integration of EJB authorization with JAX-RS Created: 28/Oct/12  Updated: 20/Oct/14

Status: Open
Project: jax-rs-spec
Component/s: server
Affects Version/s: 2.1
Fix Version/s: ice box

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified



The JAX-RS API already describes the possibility to integrate JAX-RS with EJB by simply adding the @Stateless annotation to a JAX-RS resource, and it defines the ability to access a Principal instance to find out about the current user of an authenticated request.

An EJB typically obtains automatic authorization using security annotations like @RolesAllowed. In turn, it becomes the EJB container's responsibility to prevent unauthorized callers from entering the annotated method, but automatically throw a security exception (and propagate it to the client).

As a result, it is possible to write a JAX-RS resource which is a secured EJB, using code like this:

@Stateful @Path("/stats") class UserStatistics {
  @GET @RolesAllowed("Administrators") public getSomeInterestingMetrics() {...}

Unfortunately the JAX-RS specification so far does not explicitly say how a JAX-RS implementation has to react when it finds @RolesAllowed or other security annotations. From the EJB perspective, the author of such a code would possibly want to achieve the following:

(1) The annoations are "fully operational", hence operate as described by their particular specifications.
(2) The central Java EE security provider is utilized.
(3) Non-authenticated requests, or non-authorized Principals, will not enter the resource method but instead the JAX-RS implementation responds with "403 Forbidden".
(4) The JAX-RS's automatically provided "Allow" header for an OPTIONS request will omit any HTTP methods which would be not executed following the sense of (3) when requested with the same security credentials as the OPTIONS call (i. e. either unauthenticated or authenticated as the same user).
(5) A "403 Forbidden" response will be mapped to a security exception on the client.

As a result of this assumption I want to propose to add this enhancement to an upcoming release of the JAX-RS specification.

Comment by patriot1burke [ 29/Oct/12 ]


Comment by Santiago Pericas-Geertsen [ 29/Oct/12 ]


Comment by Marek Potociar [ 30/Oct/12 ]

Targeting for future release.

Comment by patriot1burke [ 13/Nov/12 ]

Not sure I agree with the OPTIONS stufff, but the 403 Forbidden sounds pretty good, straight forward, and intuitive.

Comment by rkorn [ 02/Sep/13 ]

Are there any workarounds to "mary" EJB-role-based-security and JAX-RS security till this feature is implemented?

Comment by abhi0123 [ 17/Nov/13 ]

What about security though deployment descriptors, ejb-jar.xml + container-specific-ejb-jar.xml when deployed as an ejb-jar or web.xml + container-specific-web.xml when deployed as war? I didn't see anything clearly said in the spec about that.

Generated at Sun Feb 26 01:37:47 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.