0
votes

Using spring ACL I can configure permissions for some actions on subject. My application requires customization of access rights to a subject very rarely. So i do not want fill ACL for default dependency, but need special instruction if ACL is empty.

For example, we have

branch1
|-doc1
|-doc2
|-doc3
branch2
|-doc1
|-doc2
|-doc3

user1 belongs to branch1
user2 belongs to branch2

By default implementation user1 should have an access to all documents in branch1 (if ACL is empty). user2 -> branch2. Sometimes user1 needs special access. He needs access to branch2.doc3 and he should have a restriction for branch1.doc2!

If I try implement solution in similar way with ACL recommendations I need add permissions for each user to each document in correspond branch. This way is very ugly because of normalization && permission. So I want implement solution where ACL logic used for cross references only and default permissions allows access for any user to each document in same branch...

By default I can use method annotations like @PostAuthorize or @PreAuthorize with checks like hasRole, hasPermission, but I can not build condition where restriction by permission is stronger than role or apply filter to request based on relations user-branch.

I know this idea should be possible to implement, but I did not find correspond description or trick example how to implement it...

1

1 Answers

0
votes

I'm going to make a recommendation first:

My application requires customization of access rights to a subject very rarely. So i do not want fill ACL for default dependency, but need special instruction if ACL is empty.

Not sure this is a great idea (not saying you must not, just offering caution). This entails special logic (these guys are authorized this way, and those guys are authorized that way) which adds complexity to your app. I'll explain something about Spring Security ACLs you may not be aware of and then offer an alternate approach.

You can solve what you're asking for using the notion of parent ACLs. From the docs:

ACL_OBJECT_IDENTITY stores information for each unique domain object instance in the system. Columns include [...] the parent, a foreign key to the ACL_SID table to represent the owner of the domain object instance, and whether we allow ACL entries to inherit from any parent ACL. We have a single row for every domain object instance we’re storing ACL permissions for.

In this way, branch2 can have an acl, and branch2.doc3 can have an acl that inherits from branch2.

Using this you can chain parents, and have a root object that has your default ACL. In other words, all branches have a parent of a root object with the default ACL.

The advantage to using this approach is that it scales easier as complexity grows. You still enforce a single way, and can use arbitrarily complex logic to define your acls.