> Notes on ResourceAccessSecurity:
>
> 1) javadocs says "* - Expected to only be implemented once in the
> framework/application...", I'm not sure about that. If you have both a
> filesystem and an HBase resource providers, they might use very
> different implementations?
>
> 2) Notes as comments in the interface:
> public interface ResourceAccessSecurity {
>
> // Calling that canRead would be more consistent with other names
> public Resource checkReadPermission( Resource resource );
I choosed another naming because canCreate, canDelete, etc. returns a boolean,
but checkReadPermission returns a Resource. Maybe it's more visible with
a different methode name.
> // Having to extract username as a String feels a bit funny - maybe
> // you need an opaque ResourceCredentials object that the
> ResourceResolver can provide
> // based on a Request or Resource, similar to JCR Sessions.
> public boolean canCreate( String absPathName, String user );
At this time ResourceResolver has a method named getUserID() which
returns a String. The Javadoc of this method says:
* Get the user ID, if any, associated with this resource resolver. The
* meaning of this identifier is an implementation detail defined by the
* underlying repository. This method may return null.
If we want to use something different, we should use AuthenticationInfo, but
This is not available in ResourceResolver interface.
>
> public boolean canUpdate( Resource resource );
> public boolean canDelete( Resource resource );
> public boolean canExecute( Resource resource );
>
> public boolean canReadValue( Resource resource, String valueName );
>
> // Do we need both canCreate and canUpdate? To use canCreate you first
> need
> // to find out that the value doesn't exist, feels a bit weird.
We do need canCreate, because you could save a resource without a value on it.
The method canUpdate is the only way how a client of the ResourceAccessSecurity
service can determine if a user must not update a resource. Otherwise the client
has to check for every value which exists on the resource and also if the client
does that, it's not sure if the user can create a new value on this resource to
update
it. canUpdate returns false if the user can't update any existing value and
can't
add a new value to the given resource.
> Maybe canSetValue
> // can cover both cases, by first checking if the value exists
> public boolean canCreateValue( Resource resource, String valueName );
> public boolean canUpdateValue( Resource resource, String valueName );
Yes good point, we could make this easier with just one method.
> public boolean canDeleteValue( Resource resource, String valueName );
>
> // Does that rather belong to a QuerySecurity interface, what's
> the use case?
> // Also, user vs. ResourceCredentials as above
> public String sanitizeQuery( String query, String language, String
> user ) throws AccessSecurityException;
This method is thought for special query languages where it is very easy
to inject some things in the query which limits the resulting list of resources.
This method delegates the call to the ResourceAccessGate#sanitizeQuery.
It hasen't to be used by implementations of ResourceAccessGate, but can
be used to speed up security checks a lot. Think of a mongodb like persistence
layer with millions of resources saved. No we've got a user which has access
to only 10 resources. Now he makes a query like "SELECT * FROM allresources"
(just as an example in an SQL like language). This query would now return
millions of resources and every resource in the returning list would be checked
by ResourceAccessSecurity#canRead. With sanitizeQuery the query could
be injected with some limiting statements like "SELECT * FROM allresources
WHERE owner=<userid>". In this case a list of only 10 resources would
be returned. Nevertheless every returned resource would be checked by canRead,
but the performance would be much much better than in the first case.
Best regards
mike
