Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

spring-projects-issues opened this issue Jan 22, 2008 · 2 comments


Copy link

@spring-projects-issues spring-projects-issues commented Jan 22, 2008

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.



Copy link

@spring-projects-issues spring-projects-issues commented Sep 27, 2010

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.

Copy link

@spring-projects-issues spring-projects-issues commented Jan 12, 2011

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant