3 Replies Latest reply on Jul 14, 2008 8:58 AM by jervisliu

    Seam 2.1 security questions

    jervisliu
      Hi,

      I’ve been using some new SEAM security features in Drools project for a while, very good stuff.  Below please find two specific problems I encountered and not sure how to solve using the SEAM security API. Any suggestions or comments would be highly appreciated.

      1. Access method input parameters from the @Restrict annotation.

      It would be great if we can access method input parameters from the @Restrict annotation.  Ideally I would like to use sth like below:

      @Restrict("#{s:hasPermission('ignoredanyway','update', uuid)}")
      public ValidatedResponse savePackage(String uuid) {
         …     
      }


      In the EL, the “uuid” refers to the input parameter of savePackage(String uuid)

      As this doesn’t work at the moment, I have to work around this like below, it works, but it is ugly:


      `public ValidatedResponse savePackage(String uuid) {
          if (Contexts.isSessionContextActive()) {    
              Identity.instance().checkPermission("ignoredanyway", "update", uuid);
          }
          …
      }`


      So is it a good idea to access method input parameters in @Restrict annotation? Or there are other recommended ways to do this?

      2. Question about Identity. hasPermission(String name, String action, Object...arg)

      I have a scenario where I need to check if the user can be granted permission based on the specific object he/she is operating on. An example of this is Identity.instance().checkPermission("ignoredanyway", "update", uuid). Under the scene, the called is delegated to my own PermissionResolver to check if the current user has permission to operate the update operation on the specific object whose uuid is xxx.  However I found two problems with this API. Firstly, the first input parameter is simply ignored when the third parameter is provided (See Identity’s public boolean hasPermission(String name, String action, Object...arg) method. ). Secondly, the PermissionResolver doesn’t have a corresponding API which takes three input parameters, so the call of  Identity.checkPermission(String name, String action, Object...arg) can not be delegated to my own PermissionResolver implementation.

      Is there any way to fix this?

      Thanks,
      Jervis Liu
        • 1. Re: Seam 2.1 security questions
          pmuir

          1) I guess file a feature request in JIRA.

          • 2. Re: Seam 2.1 security questions
            shane.bryzak

            Parameter-based @Restrict is not supported, and it won't be in the future.  In Seam 2.1.0 you can instead use the typesafe security annotations to achieve what you want.


            The permission API has changed drastically in 2.1.0 (and to an extent the definition of what a permission actually is).  In the new security model, a permission consists of a target (the object on which you wish to act upon), an action (an arbitrary string) and the recipient (implied as being the current user when performing a permission check).  Your permission check will need to be structured accordingly, i.e. the object you wish to perform an update (the action) on will be the target.  You can then write a rule-based permission to examine the uuid property of that object and grant the permission accordingly.

            • 3. Re: Seam 2.1 security questions
              jervisliu


              Parameter-based @Restrict is not supported, and it won't be in the future. In Seam 2.1.0 you can instead use the typesafe security annotations to achieve what you want.

              Parameter-based @Restrict wont be supported because we can use typesafe security annotations as an alternative?  Not sure if you have mentioned how to use this typesafe security annotations in your security article, but I am afraid I still can not open your article using this url: http://shane.bryzak.com/blog/articles/seamsecuritygetsanupgrade. Would you mind sending me a copy through email please? (jliu at redhat.com)




              The permission API has changed drastically in 2.1.0 (and to an extent the definition of what a permission actually is). In the new security model, a permission consists of a target (the object on which you wish to act upon), an action (an arbitrary string) and the recipient (implied as being the current user when performing a permission check). Your permission check will need to be structured accordingly, i.e. the object you wish to perform an update (the action) on will be the target. You can then write a rule-based permission to examine the uuid property of that object and grant the permission accordingly.

              Again, is there any example of how to use this feature, I dont see it in the code base. Or it is also mentioned in your article?


              Thanks.