On 11/22/2013 06:57 PM, Tristan Tarrant wrote: > 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.
I was questioning about having EXEC without any other permission... What a user/role can do only with EXEC? >> 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 ?). good point. So, I don't see the goal of BULK permission. why don't allow the user/role to invoke the keySet/etc... if he has READ permission and the same thing for the WRITE permission? My point here is the relation between the permission is not clear (for me). BTW, one question: are we going to support to store keys under different permissions? Like some keys are private to a user and he is the only one that can read and write over it, other keys are public and everybody can access it (like a filesystem permissions: permission for the user, role and others) >> 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. +1 >> * 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. so the interceptors are for what I just said above in this reply? >> >> 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 > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
