Posts Tagged ‘acegi security plugin


Integration of Spring Security into Grails – plugin approach 3

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: [,] // which concrete permissions will be checked if 'ACL_REPORT_WRITE' is specified
			aclReportDeleteVoter: [
			domainObjectClass: 'Report',
			roleName: 'ACL_REPORT_DELETE',
			permissions: []			

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:

  1. 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.
  2. 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.
  3. 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 2

As mentioned in the last post, subject of this post will be the implementation of ACL method invocation security within the acegi security plugin 0.5.1 . In addition to that I will describe the implementation of domain objects which work with the standard JDBCMutableAclService. The next and last post of this series will present the working plugin version with corresponding documentation.

Let us begin with a description of the ACL method invocation security. The biggest challenge was to provide a solution for user based creation of custom voters. These voters are needed if you want to check method parameters with ACLs. An example method for this may look as follows:

def delete(Image image) {
	// do stuff

In this case the image parameter will be checked for existing acls concerning the calling user. If the user does not have correct permissions on the passed image object an access denied exception will be thrown. The configuration of this functionality assumes that the application developer defined a custom voter before, which handles permissions for image objects. A definition of a voter like this in plain Spring Security could look similar to the following example (from contacts sample app):

<!-- An access decision voter that reads ACL_CONTACT_DELETE configuration settings -->
  <bean id="aclContactDeleteVoter" class="">
    <constructor-arg ref="aclService"/>
    <constructor-arg value="ACL_CONTACT_DELETE"/>
        <ref local=""/>
        <ref local=""/>
    <property name="processDomainObjectClass" value=""/>

After this definition the voter has to be registered to an access decision manager with the following example configuration (look at aclContactDeleteVoter):

<!-- An access decision manager used by the business objects -->
  <bean id="aclAccessDecisionManager"
    <property name="allowIfAllAbstainDecisions" value="false"/>
    <property name="decisionVoters">
        <ref local="aclContactDeleteVoter"/>

(To make this blog post as compact as possible an example for a concrete usage definition of the voter on a method was omitted. Please look at the contacts sample application of the spring security distribution for details)

As these associations and voters can vary from application to application the plugin developer cannot guess which voters maybe needed in advance. This is not a problem because the acegi plugin takes care of an own configuration file (SecurityConfig.groovy) which can be used to provide user defined configurations. In my case I used a list and map based configuration approach which will be described in detail in the next part of this series.

Another problem however is very challenging. Grails BeanBuilder DSL is very handy when dynamically defining Spring Beans and in a plugin this is done within the doWithSpring closure. An implementation of the access decision manager mentioned above would be similar to this:

      decisionVoters=[//aclentryvoters are added within doWithApplicationContext

The omission of the custom voters in this example reveals the problem. To dynamically represent the definition of the aclAccessDecisionManager from the xml example you would have to iterate over the user configurations and dynamically add beans to the list of decision voters.
As far as I know this is impossible because a list definition of decision voters would expect one Java type for a list entry. This means, eg., that ref(“roleVoter”) must be represented as a String in a List of role voters and then injected into the decision voters list of the aclAccessDecisionManager. Regrettably this does not work because a String representation of ref(“roleVoter”) does not reflect the special role of the ref-construct.

Fortunately I found a workaround to this problem in the Spring Security API by following a two phase approach. While inspecting the Spring Security API I discovered that it is possible to change the decision voter definition at runtime . In this way it is possible to first create voters with definite names from the user security configuration. After the creation of the voters in the plugin doWithSpring closure these definite names together with the predefined aclAccessDecisionManager bean can be used to retrieve the corresponding bean instances within the doWithApplicationContext plugin closure. Again after retrieving the bean instances of the voters they can be added to the aclAccessDecisionManager with the help of its public void setDecisionVoters(List newList) method and ACL method invocation security will work :-).

Another issue of the implementation so far was the fact that a custom spring bean was needed to initialize the database schema for the JDBCMutableAclService. This was not very grails like and so I decided to implement domain classes which “create” the schema. For this to work the GORM had to be exactly the same as the manual creation of the tables with plain SQL. To get this working I had to explicitly define custom table names which fortunately is possible in GORM. Additionally optimistic locking which leads to separate version column in the database had to be disabled.

In summary the documentation of the implementation in the last blog posts led to a working acegi security plugin 0.5.1 with ACL support and method invocation security. This is why the last and final blog post will only describe the usage of the plugin enhancements.


Jump to other parts of this series:


Integration of Spring Security into Grails – plugin approach 1

This blog post describes problems and challenges when porting Stephan February’s solution from acegi security and acegiSecurityPlugin 0.3 to acegiSecurityPlugin 0.5.1 and Spring Security 2.0.5.

One issue was the fact that the whole API names changed from acegi security to spring security and that few api calls changed. Also the libraries had to be changed to work with Spring Security 2.0.5. In this case the grails maven project of the “Spring Way” mentioned before was of great help because maven’s calculated dependencies could simply be copied to the plugin. In this way all Java method.invocation errors went away magically :-). Regrettably the domain classes of Stephan’s solution could not be used any further because the whole schema had changed from Acegi security to Spring Security. That is why I decided to continue the usage of the standard JDBCMutableAclService of Spring in combination with a simple Spring bean which controls the deletion and creation of schemata with plain SQL commands.

Apart from these issues I learned to work with the Grails plugin and the Spring Security API and digged deeper into interceptor technology, expando meta classes, the Grails Bean Builder DSL and Spring Security as a whole.

I already mentioned that our Image Site makes use of very fine grained permission control for which reason it was not acceptable to us that Stephan’s solution did not support applying ACLs (Access Control Lists) to method parameters. For example this could turn out to be very useful if a user wants to delete an image and the deletion method is able to check whether the user has the correct permission on the given image object. This is the reason why I tried to implement applying ACLs to method parameters. Details of the implementation and arising problems will be subject to my next blog post.


Jump to other parts of this series: