ACL DAOs

[dreed]

Hi:

I have an application with multiple classes that use ACL-permissioning to control access to individual instances. I would prefer to keep the ACL info for each domain class separate. Does this mean that I should extend the ACL DAO multiple times? For example, packages like:

businessdomain1.auth.acl.dao
businessdomain2.auth.acl.dao

Where in each package there is a class that extends net.sf.acegisecurity.acl.basic.jdbc.JdbcExtendedDa oImpl and overwrites the SQL string to query a different database table that contains ACL permission information?

Thanks,

Dave

[Ben Alex]

Recall that AclProviderManager allows a list of AclProvider instances to be assigned against its setProviders(List) method. So what you do is use this to progressively poll multiple AclProviders until one "supports" your domain object.

The BasicAclProvider (which implements AclProvider) class provides a setRestrictSupportToClass(Class) method. This default to null, meaning the BasicAclProvider believes its underlaying BasicAclDao knows about every possible domain object instance. So you'd just set restrictSupportToClass to one domain object, and repeat the process for different domain objects.

[dreed]

Ben:

Thanks for the reply. Just to clarify, the default schema has tables for acl_object_identity and acl_permission. Instead of lumping all permissions into these two tables, what I'd like to do is have something like domain_class1_acl_object_identity, domain_class1_acl_permission, domain_class2_acl_object_identity, domain_class2_acl_permission, etc. Doesn't this mean I'll need a different ACL DAO for each secured domain object? Does it seem legitimate to want to keep ACL instance data for each secured domain object in separate tables in the first place?

Thanks again for your help

Dave

[Ben Alex]

You've got five main options:

1. Write your own AclManager framework. A lot of work.

2. Write your own AclProvider implementation. A lot of work, but slightly less than option 1.

3. Have multiple BasicAclProviders and each BasicAclProvider instance has its own BasicAclDao instance which stores the ACL permissions for just one domain object instance.

4. Write a more intelligent BasicAclDao, which talks to different tables. You could even have the "switching" between different BasicAclDaos take place at this level.

5. Put them all into one table. I honestly can't see any problem with this. Modern database can very impressively handle millions of ACL rows on commodity-level hardware. The standard schema imposes negligible constaints on database performance.

[dreed]

Ben: Thanks for your input -- this is very helpful!