[infinispan-dev] Infinispan Security

[Pedro Ruivo]

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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>