Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.1-incubating
    • Fix Version/s: 0.2-incubating
    • Component/s: Security-Module
    • Labels:
      None

      Description

      this feature is listed at https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking and part of myfaces codi-core.

      @Secured is a simple cdi interceptor annotation which allows to filter method calls to cdi beans based on custom rules.

      it's possible to specify 1-n custom implementations of AccessDecisionVoter. those voters get invoked before the call is forwarded to the target method (a voter is a cdi bean which gets resolved by its concrete type). an implementation of AccessDecisionVoter can access the InvocationContext to get further details about the target method to trigger the corresponding evaluation. as a result voters return a set of violations (SecurityViolation). if there is no violation, the target-method gets executed. if there is at least one violation, an AccessDeniedException will be thrown.

      in addition an AccessDecisionVoterContext is needed to detect if there is an ongoing security check (e.g. it's possible to use it in a custom scope to avoid that a security check postpones the expiration).
      (in myfaces codi it's also used to secure views via view-configs, however, we will exclude this part for now.)

      users can use those simple and generic apis to implement their own access control and it will get used by other deltaspike modules automatically (if they use the security-api).
      (in an AccessDecisionVoter it's possible to integrate 3rd party security-frameworks.)

      usage of @Secured:
      //...
      @Secured(

      {MyAccessDecisionVoter1.class, MyAccessDecisionVoter2.class}

      )
      public class SecuredBean

      { //... }

        Issue Links

          Activity

          Hide
          Mark Struberg added a comment -

          shipped in deltaspike-0.2-incubating

          Show
          Mark Struberg added a comment - shipped in deltaspike-0.2-incubating
          Hide
          Gerhard Petracek added a comment -

          we agreed on adding it based on DELTASPIKE-65 -> we will review the result

          Show
          Gerhard Petracek added a comment - we agreed on adding it based on DELTASPIKE-65 -> we will review the result
          Hide
          Shane Bryzak added a comment -

          In Seam Security we have a system of typesafe security annotations. Essentially, it's up to the developer to create the annotations required for the authorization checks in their application. The security binding annotations are annotated with @SecurityBindingType, here's an example:

          @SecurityBindingType
          @Retention(RetentionPolicy.RUNTIME)
          @Target(

          {ElementType.TYPE, ElementType.METHOD}

          )
          public @interface Admin {
          }

          The annotation may declare member variables also which are taken into account for the authorization check, unless the member is annotated @Nonbinding.

          Authorizer methods are used to determine whether a user has sufficient privileges to invoke a secured method. The @Secures annotation is used in combination with the security binding type annotation to declare the authorizer method, eg:

          public @Secures @Admin boolean isAdmin(Identity identity)

          { return identity.hasRole("admin", "USERS", "GROUP"); }

          This allows combinations of security binding types to be declared on a single method or class, and also has the advantage of allowing the user to declare all of their security "business logic" in a single bean. Once the security binding type annotation and the authorizer method is declared, it is then a simple matter of applying the annotation:

          @Admin
          public void doSomethingRestricted()

          { messages.info("doSomethingRestricted() invoked"); }
          Show
          Shane Bryzak added a comment - In Seam Security we have a system of typesafe security annotations. Essentially, it's up to the developer to create the annotations required for the authorization checks in their application. The security binding annotations are annotated with @SecurityBindingType, here's an example: @SecurityBindingType @Retention(RetentionPolicy.RUNTIME) @Target( {ElementType.TYPE, ElementType.METHOD} ) public @interface Admin { } The annotation may declare member variables also which are taken into account for the authorization check, unless the member is annotated @Nonbinding. Authorizer methods are used to determine whether a user has sufficient privileges to invoke a secured method. The @Secures annotation is used in combination with the security binding type annotation to declare the authorizer method, eg: public @Secures @Admin boolean isAdmin(Identity identity) { return identity.hasRole("admin", "USERS", "GROUP"); } This allows combinations of security binding types to be declared on a single method or class, and also has the advantage of allowing the user to declare all of their security "business logic" in a single bean. Once the security binding type annotation and the authorizer method is declared, it is then a simple matter of applying the annotation: @Admin public void doSomethingRestricted() { messages.info("doSomethingRestricted() invoked"); }
          Hide
          Gerhard Petracek added a comment -

          small addition (if we agree on the basic concept):
          i would suggest to change the parameter (of AccessDecisionVoter#checkPermission) to a context (e.g. the AccessDecisionVoterContext itself) which provides access to the current InvocationContext and which allows to add the violations in an easier manner.

          Show
          Gerhard Petracek added a comment - small addition (if we agree on the basic concept): i would suggest to change the parameter (of AccessDecisionVoter#checkPermission) to a context (e.g. the AccessDecisionVoterContext itself) which provides access to the current InvocationContext and which allows to add the violations in an easier manner.

            People

            • Assignee:
              Gerhard Petracek
              Reporter:
              Gerhard Petracek
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development