Apr 8th, 2005, 02:26 AM
Does ACL scale up?
In a system we're building, we are making extensive use of the ACL. For example, we have a bunch of objects:
User (which can be edited by the user himself only)
Blog (which is edited by the user and his friends)
Blog entry (which can be edited/deleted by user or admin)
For each one of these items, there's an object_identity row, and then a bunch of permissions rows that reference them.
Based on this system, we're going to have a LOT of rows... one for every object in the system. Seems kind of scary.
Is this going to scale ok? Is the proper thing to have all the security info in the ACL, or is it OK to have some small set of security in the business logic, like simple checking of whether the user is the creator of the object.
Does anyone have any data on how this scales?
Apr 8th, 2005, 07:14 PM
Like all questions of this nature, your best bet is to write a data populator that adds data to model your production situation and see how well it performs.
The out-of-the-box ACL schema could be normalised better, although it is more than adequate for most situations.
You are free to write your own BasicAclExtendedDao implementation which would be able to source your data from any location you like. Including inferring it directly from the domain model. Indeed this is not that unusual, and is why BasicAclProvider has a restrictSupportToClass property. So you can chain a few BasicAclProviders - with dedicated ones for critical domain objects with special needs and a general "catch all" for the rest.
Of course, you can also use good old AccessDecisionVoters and avoid ACLs. But I'd encourage use of the ACL services given they'll afford you much richer functionality and future flexibility.