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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
