Spring security grants permissions on domain objects indirectly via the ObjectIdentity interface.
As you mention, by far the usual case is that you create or obtain the domain object first, and then construct a ObjectIdentityImpl
for the domain object:
MyDomainObject secured = new MyDomainObject();
ObjectIdentity securedIdentity = new ObjectIdentityImpl(secured);
You then use the ObjectIdentity
instance to retrieve the ACL using the spring security framework.
However, this is not the only way to use object identity. You can pass a reference to objectIdentity that is not the actual business object, but has some means of identifying it, if it were created.
For example, imagine we wanted to secure files. We could create ObjectItentity with a java.io.File
instance that is being secured. The File
object that is in the identity is only a reference to the file - it no the actual file - the file may not even exist, yet we have an ObjectIdentity that we can then reason about security and fetch ACLs for.
This pattern can be applied to any kind of domain object. Create an DomainObjectPrototype
implementation that describes the domain object in terms of the domain features needed to secure it, but doesn't actually need a reference to the domain object. YOu can think of this as the details needed for some service to actually create that domain object.
PS: let me confess that I've never used spring security, but the design pattern seems pretty clear to me after looking at an example.
EDIT: I've updated this to hopefully make it clearer - it's not necessary to create implementations of ObjectIdentity as I originaly wrote.