Using ACLs when all you have is the object id

[ceracm]

Hi,

I just started looking at the ACL mechanism.
As far as I can tell you need to have a reference to a domain object in order for the ACL mechanism to authorize access.

But what about the following scenario:
1. The service has this method:

interface EmployeeSearchService {
findEmployeesInDepartment(int departmentId, EmployeeSearchCriteria)
}

2. Only managers for that department are authorized to invoke this method

I'd like to be able to tell ACEGI that departmentId is the pk for a Department and that it must verify that the caller of this method is authorized to access that department.

I couldn't see a way to do this. It looks like I would have to retrieve the employees and then filter them somehow.

Comments?

Chris

[ericrath]

I just faced the same issue with my own application - I think changing to an object reference is the cleanest solution. I ended up changing the service method to use a domain object reference instead of the id, and added ACL authorization - no problems. In my case, loading the domain object (in addition to the acls for that object) was already happening, and using the reference provides the added benefit of type safety.

[Ben Alex]

I didn't see the return type in your interface's method signature, but you could use after-invocation filtering as I presume it's a List of Employee instances. Alternatively, write your own AccessDecisionVoter that can be configured to construct an empty Department object, call setId() with the value of the MethodInvocation argument, and then call AclManager to determine if the rights that apply for the object. That's a quick way if you didn't want to change your method signatures to accept Department instead of an integer.

[ceracm]

I didn't see the return type in your interface's method signature, but you could use after-invocation filtering as I presume it's a List of Employee instances. Alternatively, write your own AccessDecisionVoter that can be configured to construct an empty Department object, call setId() with the value of the MethodInvocation argument, and then call AclManager to determine if the rights that apply for the object. That's a quick way if you didn't want to change your method signatures to accept Department instead of an integer.

Ben,

Thanks for your response.
The method returns a list of employees but I didn't like performance consequences of using after-invocation filtering

You suggestion of creating an empty object with containing the id is an interesting one. I will look into that. Of course, it would be nice if there was a declarative way to tell Acegi to do that for :-)

This method signature is a facade and the presentation tier does not have the Department domain object to pass it.

Chris

[Ben Alex]

You might also want to look into how AclManager actually works, and particularly BasicAclProvider. For instance, you could create a more general-purpose implementation of a declarative PrimitiveAclVoter. For example, if you marked foo.SomeManager.findEmployees=PRIMITIVE_ACL_READ, your PrimitiveAclVoter would recognise the annotation, locate the first long/integer (or whatever you configured), create an Object which implements AclObjectIdentity, and the AclObjectIdentity implementation could return a NamedEntityObjectIdentity which represents the id of the primitive argument, and the class defined by the metadata. Thus you don't need to make an empty Employee object at all, and you get more reuse. If you end up writing something like this, maybe base it on BasicAclEntryVoter and perhaps consider adding it to JIRA with unit tests and I'll pop it into CVS.