Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Component/s: None
    • Labels:
      None

      Description

      Generally speaking the existing authorization annotations in Java EE (@RolesAllowed, @RunAs, etc) are very simple, elegant and sufficient for most use cases. For more complex cases, one needs to rely on programmatic authorization and perhaps write a CDI interceptor. In addition to these options, it would be very helpful to have an authorization annotation that evaluates EL to be used in the cases between the very simple and having to write a CDI interceptor. This annotation could have some specialized EL features such as access to the principal name, role checking, authentication checking and so on. Perhaps some examples are best to illustrate the concept:

      @EvaluateSecured("principalName == 'Reza'")

      @EvaluateSecured("isLoggedIn()")

      @EvaluateSecured("hasRole('dad')")

      @EvaluateSecured("hasRoles('dad', 'spouse')")

      @EvaluateSecured("hasAnyRole('dad', 'mom')")

      @EvaluateSecured("isSecureTransport()")

      Do let me know if anything needs to be explained further - I am happy to help.

      Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Activity

        Hide
        golthiryus added a comment -

        I think it should be better to standarize a CDI interceptor to implement authorization.

        Show
        golthiryus added a comment - I think it should be better to standarize a CDI interceptor to implement authorization.
        Hide
        reza_rahman added a comment -

        Not sure I understand the distinction. Can you kindly provide a brief example?

        Show
        reza_rahman added a comment - Not sure I understand the distinction. Can you kindly provide a brief example?
        Hide
        dblevins added a comment -

        This is really interesting. Presumably there is some backing bean for this. Guessing this is where a standard `SecurityContext` object comes in? (we've definitely needed that for years)

        Inspires two thoughts

        Claims: Things like JWT and and OpenID have concepts like Claims, which is a fancy term for name=value pairs. Seems this could be some potential way to use them for authorization. I had thought about them previously and @RolesAllowed doesn't really cover that. Can only handle a list of single values, not tuples.

        Bean Validation: Has me wondering if this idea isn't some creative way to pull Bean Validation in on authorization.

        Show
        dblevins added a comment - This is really interesting. Presumably there is some backing bean for this. Guessing this is where a standard `SecurityContext` object comes in? (we've definitely needed that for years) Inspires two thoughts Claims: Things like JWT and and OpenID have concepts like Claims, which is a fancy term for name=value pairs. Seems this could be some potential way to use them for authorization. I had thought about them previously and @RolesAllowed doesn't really cover that. Can only handle a list of single values, not tuples. Bean Validation: Has me wondering if this idea isn't some creative way to pull Bean Validation in on authorization.
        Hide
        arjan tijms added a comment -

        Has me wondering if this idea isn't some creative way to pull Bean Validation in on authorization.

        Indeed, and I have been experimenting with exactly this a little. Just an @RolesAllowed clone for now, but to get the idea see: https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/constraints/RolesAllowedValidator.java

        One thing we might want to think about is the priority of this interceptor relative to other interceptors. Bean Validation I believe is at a fixed priority, while interceptor spec interceptors can be given a specific priority.

        Another thing concerns the scope and implicit variables in that scope of the EL expression. For instance, in "principalName == 'Reza'", it's assumed there's an EL variable called "principalName" in the current scope.

        Where does this name come from (who produces it in CDI terms), what will the scope exactly be and what will be the full list of implicit variables?

        The platform wide security context could indeed be used here, but then I guess we might want to make that context itself an EL variable (e.g. "context"). The EL expression would then become e.g.: "context.userName == 'Reza'"

        Show
        arjan tijms added a comment - Has me wondering if this idea isn't some creative way to pull Bean Validation in on authorization. Indeed, and I have been experimenting with exactly this a little. Just an @RolesAllowed clone for now, but to get the idea see: https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/constraints/RolesAllowedValidator.java One thing we might want to think about is the priority of this interceptor relative to other interceptors. Bean Validation I believe is at a fixed priority, while interceptor spec interceptors can be given a specific priority. Another thing concerns the scope and implicit variables in that scope of the EL expression. For instance, in "principalName == 'Reza'" , it's assumed there's an EL variable called "principalName" in the current scope. Where does this name come from (who produces it in CDI terms), what will the scope exactly be and what will be the full list of implicit variables? The platform wide security context could indeed be used here, but then I guess we might want to make that context itself an EL variable (e.g. "context"). The EL expression would then become e.g.: "context.userName == 'Reza'"

          People

          • Assignee:
            alex.kosowski
            Reporter:
            reza_rahman
          • Votes:
            11 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated: