Securing Hibernate persisted objects with ACLs

[stachs]

Hi

I the web appliaction I'm working on I need to secure access to objects which are persisted using Hibernate. Those objects are plain POJOs without any businness methods (only setters/getters). Those objects are used by service layer which loads them from database etc. My question is: how to apply ACL checks in such case. Is there a way for a Method Invocation Interceptor to secure those objects even though no methods of those object will be called ? Or should I parse Http Invocations for, let's say, projectId parameter and check ACL permissions using a custom voter ?

Any suggestions will be appreciated

[eisenb]

Others may be able to answer this question, but I at least feel like more info is needed.

Are you securing the get/set method calls on these POJOs? Or is the security scenario just protecting the acquisition of the instance itself?

Perhaps if you elaborated just a bit more on your request / response flow others might be able to give you a more informed opinion on what to do.

Bill

[stachs]

In my application I want to secure projects. Depending on a role in the project user has different rights to the project. For example a project manager can assign other people to the project and assign roles to them. Project analyst can add analysis of the project, project developer can add reports for the project and so on.
So the roles for the same user can be different for different projectsand depending on a role in the project user can access different screens and service methods.
Users also have global roles, basically ROLE_USER, ROLE_DIRECTOR, ROLE_ADMIN.
Only admin and director can add new projects to the system and assign a project manager to take care of the details.

Currently I think of 2 solutions:
* Securing service layer method invocations depending on passed projectId parameter
* securing Http invocations parsing URL for projectId parameter
Both solutions require writing custom decision voter which will check the ACL against current project and user.
I'd rather not use ACL database tables used by integer masked ACL implemenation, but draw the access information from the domain model
(this information is there anyway so why duplicate it...) (I have Users, Projects, Roles and Users_in_projects tables)

Hope this makes my question a little bit more specific

[Ben Alex]

You can do it in a number of way, but I wouldn't do it at the HTTP request level as that's quite fragile:

- Use standard ACL security with its standard dedicated tables
- Provide a custom BasicAclDao that retrieves ACL data from your existing domain model, not the standard dedicated ACL tables
- Provide a custom AccessDecisionVoter that looks at the method invocation

Your problem with the AccessDecisionVoter is it cannot filter objects after the invocation, and it's also not terribly robust with non-domain object arguments. For example, a common getById(Long id) method wouldn't work with an AccessDecisionVoter.

If it were my project, I'd do one of the first two options above. This gives you the maximum flexibility.

[stachs]

Thanks for help, I think I'll use the second proposed solution.

I have one more question. Which intercteptor is it best to use in this scenario ? I would like to control service methods like:

public boolean assignUserToRoleInProject(Long projectId, Long userId, Long roleId)

How do I draw the ACL permissions based on projectId before checking the method invocation itself?

I would like to use an ObjectDefinitionSource like this:

<property name="objectDefinitionSource">
    <value>
        sample.application.assignUserToRole=PROJECT_MANAGER
    </value>
</property>

In this case only the PROJECT_MANAGER for the project with id passed as a method parameter can use this method. Is it possible to achieve this with Acegi ?

[Ben Alex]

If your assignUserToRoleInProject passes the Project domain object instead of the projectId, the standard Acegi Security classes will work fine. I'd generally recommend you pass actual domain objects around in method arguments instead of their identifiers, as identifiers lack the benefit of strict type checking.