SEC-642: More Abstract ACL to handle Class/Field level security

[spring-projects-issues]

Troy J. Kelley(Migrated from SEC-642) said:

It seems the ACL design is targeted at providing security for object instances, which is great if you need very detailed authorization. However, it seems that the API limits one from applying the ACL concept to other Use Cases. Namely the following:
1. ACL at the Class level (Authorization requirements not based on context or instances)
2. ACL at the field level
3. Others?

This would require the ACL class to be a bit more abstract. Instead of referring to an ObjectIdentity, maybe it could be a more generic “ResourceIdentity” with a name and a simple identity. Additionally, it seems a ResourceIdentityRetrievalStrategy would be added, which ObjectIdentityRetrievalStrategyImpl would implement.

Class and Field level security tags for the font-end might look like:

This would be equally useful with the back-end ACL features as well. One more example might be to use Class-level security when a mixed collection of Objects sharing a common supertype are returned. A post collection filter could be used to remove those Classes for which the user is not authorized to view.

It’s quite possible that I’m missing the alternative approach to addressing my Use Cases. In order to use the ACL concept for my Use Cases, I would need to supplant the existing ACL class (since extending it would not be very clean) with my own which is quite a bit of work and a little risky.

Thanks,

-Troy

[spring-projects-issues]

Brian Relph said:

I think both of your listed use cases can be solved using the existing ACL class - it just takes a slight shift in determining what ObjectId you are securing:

1. ACL at the class level - I would approach this use case as wanting to secure an ObjectId with type = "java.lang.Class" and id = "DomainClass".

2. ACL at the field level - I would approach this use case as wanting to secure an ObjectId with type = "java.lang..reflect.Method" and id = "DomainClass.method". Alternatively, you could use an ObjectId with type = "DomainClass" and id = "method", but this might get confusing if you were also storing ACLs for instances of the same domain class.

[spring-projects-issues]

Luke Taylor said:

Closing as "won't fix". As mentioned above, it is probably possible to achieve greater flexibility within the existing classes without introducing the suggested additional strategy, particularly since the "type" property of ObjectIdentifier is no longer constrained to be a Class object, but is now a String. So the data to which the permissions apply is only defined by an abstract label and does not have to be an instance of a specific class.