Confused by ACLs :-)

[aaime]

I'm currently desining a system that requires the use of ACLs, but I'm finding it difficult to come up with an architecture when I think about the AclEntry creation. (it's the first time I need ACL based security, I managed to live and program only role based systems so far ;-) )
I mean, once the ACL list has been created, it's quite clear how to use it, but what are, in general, the approach to create the ACLEntries in the first place?
For sure we don't want the user to insert privileges for every created object, so there must be a reasonable default for it.
Also, I'm not sure about how to mix authorities based authorization with ACL based one. Using voters imply that a user need both the authority and an entry in an ACL to do some operation on some object, right?

Is there any common approach? Anyone willing to share his experience?

[aaime]

I'm looking at the source code and noticed that in SimpleAclEntry (CVS version) there are permissions such as ADMINISTRATION and CREATE...
Since there is no Javadoc, I'm wondering about their meaning.

I suppose Administration means the ability to change the permissions themselves?
And what about CREATE? I thought that object creation is something that needs to be addressed by role based security. What is the meaning of adding a CREATE permission to an object?
Does it mean that the object is a container and that the privilege is needed to add childs to it? Or that there is somewhere a shared object instance that is not used as data itself, but only to store who can create other instances of this kind of object?

[Ben Alex]

The SimplAclEntry statics such as ADMINISTRATION, CREATE, DELETE etc have no JavaDocs as their meaning will vary based on your application. They're just such commonly assigned ACL permissions I felt it was useful to provide a concrete AbstractBasicAclEntry that implemented them. Feel free to subclass AbstractBasicAclEntry and define your own permissions instead, as it's very easy to do so.

In the Contacts application IIRC we're using ADMINISTRATION, which denotes the ability to modify ACLs for a domain object instance, DELETE (self explanatory) and READ (self explanatory).

Many of your services layer methods will only use role-based security. Some will use ACL security, in which case you need a way of ensuring the user has been authenticated. You typically have two ways of doing that: (i) protect the URI patterns for the entire webapp with a ROLE_USER or (ii) protect every method with a ROLE_USER. You can call ROLE_USER some other name as you see fit, of course. This will ensure if the user has not been authenticated, they will be. We've done this in the Contacts application.

In terms of when to create your ACL database rows, typically your services layer will accept a BasicAclExtendedDao implementation. This will then be called during services layer methods that create and delete your domain object instances. This is necessary (at least for creation operations) as only your services layer methods understand which domain object is the parent of the domain object being created.

I was talking to Matthew Porter who was considering using AOP to automate the creation and deletion of ACL rows, using a pluggable metadata mapping approach to discovering each domain object instance's parent. You might like to send Matthew a message to see how that went. If you only have a few domain object classes that need ACL security, it's probably easiest to just do it via your services layer. At an architectural level the services layer is supposed to manage "workflow", often between different DAOs, so I'm not of the view this is architecturally inappropriate.

[craig]

...

I was talking to Matthew Porter who was considering using AOP to automate the creation and deletion of ACL rows, using a pluggable metadata mapping approach to discovering each domain object instance's parent. You might like to send Matthew a message to see how that went. If you only have a few domain object classes that need ACL security, it's probably easiest to just do it via your services layer. At an architectural level the services layer is supposed to manage "workflow", often between different DAOs, so I'm not of the view this is architecturally inappropriate.

Has anything more come of this? I have been spending considerable time trying to devise a plan on introducing ACLIdentities at runtime. If there are others who are still considering this, or have figured out a nice solution I would be very interested in hearing more about the solution.

I did some work with Aspect J, watching addXX and removeXX methods. This would then create/remove the necessary ACLIdentities, seemlessly attaching the acl's into the current transaction. I ran into problems here because I do not have the ability to create my id's in java, they are generated within our database. (We use toplink btw). This causes problems with the NamedEntityObjectIdentity, as it expects id's, and when I was trying to create the ACLIdentities, (ie. after advice on addXXX) I just didn't have the id column yet.

I paused and rethought my strategy.

Next I was thinking I could hook in with the Toplink event model, and simply react to Insert/Delete object events. This has the the advantage of being a little simpler. The downside I see is I am coupling the ACL's, with my persistence strategy implementation. I think I can live with this, I don't see us changing off Toplink anytime soon, and I need ACL's.

I haven't used annotations yet, but using those seem like another approach with merit.

As you can see, I still have many questions. I would really appreciate some insight from others who may have already considered all this.

Thanks,

Craig

[Ben Alex]

I agree, it's an area which could be improved. I've added it to JIRA and assigned it to Matthew - hopefully if he's made any progress we can track it over there: http://opensource.atlassian.com/projects/spring/browse/SEC-19

[pzoot]

I was talking to Matthew Porter who was considering using AOP to automate the creation and deletion of ACL rows...

We've been starting to use a simple version of this idea, though we use hibernate to assign primary keys, so getting the object identity hasn't been an issue (the problem craig had). Seems to work.

One question we've just started looking into is how this kind of advice interacts with the transaction interceptor - I'm sure there is a simple answer but I can't find it. (Adding the permissions to the object has to occur within the same transaction as the 'create').

Does anybody know if an after advice interceptor will be run before or after the (around advice) closing of the transaction? I believe it does the Right Thing but if someone has a definitive answer I'd appreciate it!

[pzoot]

I can answer my own question now...and sorry if this is a bit off topic, it really is a spring aop question.

Spring will do the right thing if some care is taken in the ordering of the interceptors.

As long as our after advice (which puts in the permissions) is the first one listed after the last around advice, it will be invoked (through the call to MethodInvocation.proceed() in the around advice) before the closing of the transaction.

It would still be nice if this was documented clearly somewhere, it isn't obvious!