jax-rs-spec
  1. jax-rs-spec
  2. JAX_RS_SPEC-304

Integration of EJB authorization with JAX-RS

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: ice box
    • Component/s: server
    • Labels:
      None
    • Environment:

      EJB

      Description

      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.

        Activity

        Hide
        patriot1burke added a comment -

        +1.

        Show
        patriot1burke added a comment - +1.
        Hide
        Santiago Pericas-Geertsen added a comment -

        +1

        Show
        Santiago Pericas-Geertsen added a comment - +1
        Hide
        Marek Potociar added a comment -

        Targeting for future release.

        Show
        Marek Potociar added a comment - Targeting for future release.
        Hide
        patriot1burke added a comment -

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

        Show
        patriot1burke added a comment - Not sure I agree with the OPTIONS stufff, but the 403 Forbidden sounds pretty good, straight forward, and intuitive.
        Hide
        rkorn added a comment -

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

        Show
        rkorn added a comment - Are there any workarounds to "mary" EJB-role-based-security and JAX-RS security till this feature is implemented?
        Hide
        abhi0123 added a comment -

        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.

        Show
        abhi0123 added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            mkarg
          • Votes:
            4 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: