ANN: Spring Security ACL Plugin 0.1 released

[burtbeckwith]

I've released the Spring Security ACL plugin. It depends on the Spring Security Core plugin and adds ACL support to guard access to individual domain class instances. Like the core plugin, this only works with Grails 1.2.2 and above.

This is an official Grails plugin, so the code is hosted at http://github.com/grails-plugins/grails-spring-security-acl

The standard wiki page is http://grails.org/plugin/spring-security-acl but there is documentation at http://burtbeckwith.github.com/grails-spring-security-acl/

Feedback, suggestions for improvement and contributions are always welcome. Please report any bugs or feature requests on the user list or in JIRA at http://jira.codehaus.org/browse/GRAILSPLUGINS under the 'Grails-Spring-Security-ACL' component.

Burt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Müller, Wolfgang]

Great!
Do you think this could work with 1.3., too?
Cheers,
Wolfgang

On Sat, May 22, 2010 at 7:24 AM, Burt Beckwith <[hidden email]> wrote:

I've released the Spring Security ACL plugin. It depends on the Spring Security Core plugin and adds ACL support to guard access to individual domain class instances. Like the core plugin, this only works with Grails 1.2.2 and above.

This is an official Grails plugin, so the code is hosted at http://github.com/grails-plugins/grails-spring-security-acl

The standard wiki page is http://grails.org/plugin/spring-security-acl but there is documentation at http://burtbeckwith.github.com/grails-spring-security-acl/

Feedback, suggestions for improvement and contributions are always welcome. Please report any bugs or feature requests on the user list or in JIRA at http://jira.codehaus.org/browse/GRAILSPLUGINS under the 'Grails-Spring-Security-ACL' component.

Burt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[burtbeckwith]

Absolutely - all Grails versions 1.2.2 and higher.

Burt

> Great!
> Do you think this could work with 1.3., too?
> Cheers,
> Wolfgang
>
> On Sat, May 22, 2010 at 7:24 AM, Burt Beckwith <[hidden email]>wrote:
>
> > I've released the Spring Security ACL plugin. It depends on the Spring
> > Security Core plugin and adds ACL support to guard access to individual
> > domain class instances. Like the core plugin, this only works with Grails
> > 1.2.2 and above.
> >
> > This is an official Grails plugin, so the code is hosted at
> > http://github.com/grails-plugins/grails-spring-security-acl
> >
> > The standard wiki page is http://grails.org/plugin/spring-security-acl but
> > there is documentation at
> > http://burtbeckwith.github.com/grails-spring-security-acl/
> >
> > Feedback, suggestions for improvement and contributions are always welcome.
> > Please report any bugs or feature requests on the user list or in JIRA at
> > http://jira.codehaus.org/browse/GRAILSPLUGINS under the
> > 'Grails-Spring-Security-ACL' component.
> >
> > Burt
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
> >
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jared M]

Burt, thank you for this contribution.  I'm looking forward to using it.

[linus1412]

Hi Burt,

Am I right in thinking that you cannot use the Pre/Post annotations on Controllers/actions?  It didn't seem to work for me, and I couldn't find any examples.

So I couldn't do this...

SimpleController {
  @PreAuthorize("hasPermission(#param.id, 'com.yourapp.Person', read")
  def list = {
    // Do some stuff.....
    Person.findAllByParent(parent)
  }
}

But could do this...

SimpleController {
  def simplerService
  def list = {
    // Do some stuff.....
    simpleService.findAllByParent(parent)
  }
}

SimpleService {
  @PreAuthorize("hasPermission(#parent, 'com.yourapp.Person', read")
  def findAllByParent(parent) {
    Person.findAllByParent(parent)
  }
}

If this is the case, it seems a bit more long winded for simple actions.

I'm guessing the reason is to do with the expression language and the binding to method arguments (or lack of them) on the conttroler actions.

If that is the case, what about using a closure to enable groovy to be the expression language like this...

SimpleController {
  @PreAuthorize( { hasPermission(param.id, 'com.yourapp.Person', read } )
  def list = {
    // Do some stuff.....
    Person.findAllByParent(parent)
  }
}

I believe that closures in annotations will be supported in Groovy 1.8, and can be supported now via an AST Transformation - http://pniederw.wordpress.com/2010/03/04/3/

Martin / linus1412

[burtbeckwith]

The annotations trigger Spring AOP interception. This would probably be doable in a controller, but would be more trouble than it's worth. Controllers should be dumb routers - extracting information from the request and calling helpers, then routing to the next page. There's a tendency to do too much work in controllers since it's so easy but a service is the best place for business logic like this.

You can also easily unit test the controller if it calls "simpleService.findAllByParent(parent)" by mocking the service but it'd be a lot more work to test an annotated controller that's polluted with database calls, annotations, security metadata, etc.

Burt

>
> Hi Burt,
>
> Am I right in thinking that you cannot use the Pre/Post annotations on
> Controllers/actions?  It didn't seem to work for me, and I couldn't find any
> examples.
>
> So I couldn't do this...
>
> SimpleController {
>   @PreAuthorize("hasPermission(#param.id, 'com.yourapp.Person', read")
>   def list = {
>     // Do some stuff.....
>     Person.findAllByParent(parent)
>   }
> }
>
> But could do this...
>
> SimpleController {
>   def simplerService
>   def list = {
>     // Do some stuff.....
>     simpleService.findAllByParent(parent)
>   }
> }
>
> SimpleService {
>   @PreAuthorize("hasPermission(#parent, 'com.yourapp.Person', read")
>   def findAllByParent(parent) {
>     Person.findAllByParent(parent)
>   }
> }
>
> If this is the case, it seems a bit more long winded for simple actions.
>
> I'm guessing the reason is to do with the expression language and the
> binding to method arguments (or lack of them) on the conttroler actions.
>
> If that is the case, what about using a closure to enable groovy to be the
> expression language like this...
>
> SimpleController {
>   @PreAuthorize( { hasPermission(param.id, 'com.yourapp.Person', read } )
>   def list = {
>     // Do some stuff.....
>     Person.findAllByParent(parent)
>   }
> }
>
> I believe that closures in annotations will be supported in Groovy 1.8, and
> can be supported now via an AST Transformation -
> http://pniederw.wordpress.com/2010/03/04/3/
> http://pniederw.wordpress.com/2010/03/04/3/ 
>
> Martin / linus1412
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[linus1412]

Hello again Burt,

>> There's a tendency to do too much work in controllers since it's so easy but a service is
>> the best place for business logic like this.

I agree that some people do abuse Controllers, but some times writing a service method would be overkill.

Take a really simple scenario...

class PersonController {
  @PreAuthorize("hasPermission(#params.id, 'smitek.Person', 'read')")
  def show = {
    [person:Person.get(params.id)]
  }
}

I don't see how this would benefit being moved to a service method.

class PersonController {
  def personService
  @PreAuthorize("hasPermission(#params.id, 'smitek.Person', 'read')")
  def show = {
    [person:personService.getById(params.id)]
  }
}

class PersonService {
  @PreAuthorize("hasPermission(#id, 'smitek.Person', 'read')")
  def getById(id) {
    Person.get(params.id)
  }
}

>>  You can also easily unit test the controller if it calls "simpleService.findAllByParent(parent)" by
>>  mocking the service but it'd be a lot more work to test an annotated controller that's polluted
>>  with database calls, annotations, security metadata, etc.

With the controller calling the service, you can now easily test that the Controller interacts with the Service, but at the expense of testability of the Service method (database calls, annotations, security metadata, etc..)

Any way, don't let my moaning stop you from finishing the spring-security-ui plugin :)

And thanks for all your hard work and approachability

Martin / linus1412

[burtbeckwith]

Yes, taken out of context like that it seems like overkill. But controllers are usually a mix of actions that read and update the database. You're proposing splitting the object-level security between the controllers and the transactional services that handle the updates. I think it makes more sense to combine the transaction and security rules in the services.

Burt

>
> Hello again Burt,
>
> >> There's a tendency to do too much work in controllers since it's so easy
> >> but a service is
> >> the best place for business logic like this.
>
> I agree that some people do abuse Controllers, but some times writing a
> service method would be overkill.
>
> Take a really simple scenario...
>
> class PersonController {
>   @PreAuthorize("hasPermission(#params.id, 'smitek.Person', 'read')")
>   def show = {
>     [person:Person.get(params.id)]
>   }
> }
>
> I don't see how this would benefit being moved to a service method.
>
> class PersonController {
>   def personService
>   @PreAuthorize("hasPermission(#params.id, 'smitek.Person', 'read')")
>   def show = {
>     [person:personService.getById(params.id)]
>   }
> }
>
> class PersonService {
>   @PreAuthorize("hasPermission(#id, 'smitek.Person', 'read')")
>   def getById(id) {
>     Person.get(params.id)
>   }
> }
>
> >>  You can also easily unit test the controller if it calls
> >> "simpleService.findAllByParent(parent)" by
> >>  mocking the service but it'd be a lot more work to test an annotated
> >> controller that's polluted
> >>  with database calls, annotations, security metadata, etc.
>
> With the controller calling the service, you can now easily test that the
> Controller interacts with the Service, but at the expense of testability of
> the Service method (database calls, annotations, security metadata, etc..)
>
> Any way, don't let my moaning stop you from finishing the spring-security-ui
> plugin :)
>
> And thanks for all your hard work and approachability
>
> Martin / linus1412
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[linus1412]

I guess I'm maybe just looking at it simplistically.

I'm trying to move my app away from the Shiro plugin.  I liked Shiro's approach of constraining what URLs users could/couldn't access, but the way this was implemented (filters) just got out of hand as the app grew....

        squadCreate(controller:"squad", action:create) {
            before = {
                accessControl {
                    role('UserRole')
                }
            }
        }

        squadUpdate(controller:"squad", action:update) {
            before = {
                accessControl {
                    permission("squad:manage:${params.id}")
                }
            }
        }


I was hoping that I would be able to do the same at the Controller level with the ACL plugin via annotations.

Martin / linus1412

[burtbeckwith]

You can annotate controllers to restrict which roles are allowed to access the whole controller and/or individual actions - see http://burtbeckwith.github.com/grails-spring-security-core/docs/manual/guide/3.%20Securing%20URLs.html#3.1%20Annotations

You can also use security expressions in the annotations and these are pretty powerful - see http://burtbeckwith.github.com/grails-spring-security-core/docs/manual/guide/3.%20Securing%20URLs.html#3.4%20Expressions

You just can't apply ACL rules for domain objects at the controller level - only URL rules.

Burt

>
> I guess I'm maybe just looking at it simplistically.
>
> I'm trying to move my app away from the Shiro plugin.  I liked Shiro's
> approach of constraining what URLs users could/couldn't access, but the way
> this was implemented (filters) just got out of hand as the app grew....
>
>         squadCreate(controller:"squad", action:create) {
>             before = {
>                 accessControl {
>                     role('UserRole')
>                 }
>             }
>         }
>
>         squadUpdate(controller:"squad", action:update) {
>             before = {
>                 accessControl {
>                     permission("squad:manage:${params.id}")
>                 }
>             }
>         }
>
>
> I was hoping that I would be able to do the same at the Controller level
> with the ACL plugin via annotations.
>
> Martin / linus1412
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[linus1412]

Hi (yet again) Burt,

I have another permission question for you...

In a view I need to present the 'manager menu' if the current user has permission to manage a Squad.

I was hoping for something like this

<sec:hasPermission model="${squadInstance}" permission="manage">
 
</sec:hasPermission>

How could I achieve this?

Martin / linus1412