[infinispan-dev] Infinispan Security

[Tristan Tarrant]

On 11/22/2013 04:47 PM, Pedro Ruivo wrote:
> * About the permissions
>
> It would be good to describe what is the relation between the
> permissions. For example, answer the following question: can a
> user/group/role have READ permission over a cache without ACCESS
> permission? Can it have WRITE permission without READ (write operation
> returns the old value)?
Well, the default is to not return values, so it does make sense.
> and EXEC? does it makes sense to have EXEC
> without READ and/or WRITE?
Yes, you can certainly have an EXEC with READ only permissions.
> Since we have a BULK permission (that it is a READ) why not split the
> WRITE? like MODIFY(put* replace*), DELETE(remove*) and CLEAR(clear)?
BULK is also for WRITEs (putAll ?).
> Other thing that is not clear to me is if it is possible to specify
> default permissions. I assuming that if you define the roles in the
> <default> cache, they will be passed to the <namedCache> if nothing is
> specified, right?
Yes, this is the behaviour for all other configuration items.
> Is the secure cache protected against the ComponentRegistry? I meant, it
> is possible to do cache.getAdvancedCache().getDataContainer().clear()
> and skip any authentication?
Yes, the SecureCache is not just a dumb decorator. We also need to 
return a special type of SecureAdvancedCache which only allows access to 
certain underlying bits (such as DataContainer) if I have ADMIN role. 
Obviously, protection from reflection needs to be handled by the 
security policy installed in the JVM.
> * About the Interceptors
>
> IMO, bad idea. I think we should have a SecureCache interface and
> implementation (SecureCacheImpl). As suggested in the wiki, this
> SecureCacheImpl will throw a SecurityException in any invocation byut it
> would have a method /.as(Subject)/ that would return a decorate
> SecureCache with the correct permissions.
The interceptor is a further layer of authorization which works in 
concert with the above, so that it can allow/deny access based on the 
key/value. My idea is to provide an AuthorizationInterceptor which can 
be subclassed by the developers to implement their own data-dependent 
security policies.
>
> About the encryption I think the application should be responsible to do
> it and not the Cache. However, if it is really necessary I would do it
Yes, I also think that encryption should be handled at the application 
level. We just need to secure the transports (JGroups, HotRod, etc).
> * HotRod security
>
> In the design document, it does not refer anything to encrypt the
> communication between the clients and the server. is it a gap?
HotRod already has TLS. What we need to add here is EXTERNAL 
authentication (i.e. obtain the Subject from the certificate used to 
encrypt the transport).
>
> * Finally, some minor typos:
> ** the embedded configuration title is in the middle of the embedded API
> text
> ** the lists are all in the same line in embedded encryption and hot rod
> security
> ** Memcached Security is not "titlefied"
>
Thanks Pedro,

I will fix those and clear up the "ambiguous" bits above.

Tristan