2013/3/25 Mike Müller <[email protected]>:
>> Notes on ResourceAccessSecurity:
>>
>
> 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.

Yes and no :) I think we should pass in ResourceResolver - for one, it
has the getUserID method but it also has the getAttribute methods
which allow access to most of the stuff passed into authentication
info (except password and maybe other security related information).

Carsten

>
>
>>
>>     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



-- 
Carsten Ziegeler
[email protected]

Reply via email to