Securing the domain object with Spring ACL 3

Question

I have a RESTful service which uses the internal business service to save and fetch information from the databases. The webservice uri looks something like, /api/entity/{id}, to which the web UI application requests with the ID of the entity. Here the problem is the {id} can be literally anyone's id, that is, the record of someone else that should not be seeing by the user using the application. In order to solve this, using the Spring Security, I wrote a SPEL, something like,

@Service
interface EntityService {
    @PostAuthorize("returnObject.userId==principal.id")
    public ReturnObject get(long i);
}

Is the above approach the right way to solve this? (In my earlier projects my developers used to write all these security stuffs into their business methods.) As the complexity of the security grows for an entity, say, the administrator of the user (who have created the record) can see the object but not other administrators, or group administrators can see the record etc, this approach too gets complicated. Besides, after digging my head into many of the Spring-ACL library classes, I somehow have managed to configure the Spring-ACL, invoke its permission evaluator evaluate the hasPermission method in the SPEL with the authorization of the entity and its unique-identifier loaded from the database.

@Service
interface EntityService {
    @PreAuthorize("hasPermission(#id, 'com.project.domain.ReturnObject', 'read')")
    public ReturnObject get(long id);
}

But the problem I see with this approach is, every time a user creates a record shouldn't the application create an ACL permission too (ACL_ENTRY) for that object? Is this a right way to approach this problem, or is there some other way I didn't see through? I know this is not a new problem, and someone out there should have solved it already in many ways. I want to know how the problem was solved, not in the traditional way, in the service logic or in the queries, but using frameworks such as Spring-ACL or Apache Shiro.

Answer 1

I can't answer if Shiro uses a different approach, but as Neil commented earlier,

Spring Security does not provide any special integration to automatically create, update or delete ACLs as part of your DAO or repository operations. Instead, you will need to write code [...] for your individual domain objects

— Spring Security Reference: Domain Object-based ACLs

The open-source OACC security framework (disclosure: I'm maintainer and co-author), on the other hand has the concept of create-permissions, which let you define exactly what permissions a user would get on an object after creating it.

OACC is an API designed to help you manage and query your permissions and security topology programmatically.
It supports fine-grained permissions on your individual domain objects, lets you model coarse-grained roles, and with its concepts of domains, permission inheritance and impersonation, can handle pretty much anything in between.