Issue Details (XML | Word | Printable)

Key: JAX_RS_SPEC-304
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: mkarg
Votes: 4
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
jax-rs-spec

Integration of EJB authorization with JAX-RS

Created: 28/Oct/12 12:52 PM   Updated: 17/Nov/13 03:34 AM
Component/s: server
Affects Version/s: 2.0
Fix Version/s: ice box

Time Tracking:
Not Specified

Environment:

EJB


Tags:
Participants: abhi0123, Marek Potociar, mkarg, patriot1burke, rkorn and Santiago Pericas-Geertsen


 Description  « Hide

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.



patriot1burke added a comment - 29/Oct/12 12:04 AM

+1.


Santiago Pericas-Geertsen added a comment - 29/Oct/12 02:36 PM

+1


Marek Potociar added a comment - 30/Oct/12 03:17 PM

Targeting for future release.


patriot1burke added a comment - 13/Nov/12 04:39 PM

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


rkorn added a comment - 02/Sep/13 08:21 AM

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


abhi0123 added a comment - 17/Nov/13 03:34 AM

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.