In this post, as mentioned earlier, I will explain how my spring security 2.0.5 ACL (access control list) enhancement of the acegi security plugin 0.5.1 for Grails can be configured. My work bases on Stephan February’s solution for the 0.3 plugin version and acegi security. Apart from the implementation changes within the plugin, the plugin configuration only has minor changes. This is the reason why it is strongly advised to read Stephan’s blog post before continuing with this article as I will only mention major differences between the configuration of his plugin version and mine.
One difference in my version is the possibility of applying ACLs to method parameters (see 2.1 for an example):
For this to work custom voters have to be defined. A custom definition for the example of Stephan’s blog post looks as follows:
springSecACLVoters = [ //this map must be called 'springSecACLVoters' aclReportWriteVoter: [// custom beanName domainObjectClass: 'Report', // which type of domainclass will be secured roleName: 'ACL_REPORT_WRITE', // under which name the voter should be referenced later? Must start with 'ACL_' permissions: [ org.springframework.security.acls.domain.BasePermission.ADMINISTRATION, org.springframework.security.acls.domain.BasePermission.WRITE] // which concrete permissions will be checked if 'ACL_REPORT_WRITE' is specified ], aclReportDeleteVoter: [ domainObjectClass: 'Report', roleName: 'ACL_REPORT_DELETE', permissions: [ org.springframework.security.acls.domain.BasePermission.DELETE] ] ]
I added comments in the corresponding lines to describe the single options in detail. As you can see more than one voter can be defined as long as the map name is ‘springSecACLVoters’ and the map is defined in SecurityConfig.groovy. Please note that if you do not need method parameter checking with ACLs you can simply omit the map configuration of voters.
Aside from the definition of custom voters and for applying ACLs to method parameters I added three other options to SecurityConfig.groovy:
useAcl = true // defaults to false, optional aclClassIdentityQuery="SELECT @@IDENTITY" // this query is for MySQL, default is 'identity()' for hsqldb, optional aclSidIdentityQuery="SELECT @@IDENTITY" // this query is for MySQL, default is 'identity()' for hsqldb, optional
If you want to use ACL extensions in general useAcl must be specified and set to “true”. Furthermore the enhancement uses the default JdbcMutableAclService implementation of Spring. For this reason you must have the possibility to change its identity queries (look here) to match your database. This can be done with the two corresponding options. The code snippet above shows working example values for hsqldb and MySQL.
Apart from feature and configuration changes the infrastructure of the plugin did also undergo a change since Stephan’s version: Because of the move of the ACL domain classes into the plugin domain directory the Gant target “CreateAclDomains” is no longer needed.
Therewith the description of the plugin configuration is complete. Some issues however remain to be done:
- Calling of acl security functionality when using ‘run-app’ may raise a class not found exception which will not be raised when ‘run-war’ is used. I have to examine this more precisely and eventually file a bug report.
- Test cases should be developed before a possible integration of the code into the main acegi security plugin tree. I am in contact with Burt Beckwith to get this working.
- I have to upload the code to the GRAILSPLUGINS-723 JIRA task so that Burt Beckwith can decide on a possible integration into the acegi plugin version control tree. I will do this within the next week as I am very busy at the moment.
I hope this helps somebody
Feedback is greatly appreciated
Jump to other parts of this series:
- Integration of Spring Security into Grails – plugin approach 3
- Integration of Spring Security into Grails – plugin approach 2
- Integration of Spring Security into Grails – plugin approach 1
- Integration of Spring Security into Grails – Spring approach
- The Decision