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:
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.