2:05 p.m.
Hi all,
I've published an ongoing draft of how we should implement Security in
Infinispan.
https://github.com/infinispan/infinispan/wiki/Security
There are still gaps in there, but I'd like your comments early :)
Tristan
4:47 p.m.
Hi,
I took a look at the document and these are my comments :)
(note: I only have the basic knowledge of security: security is a myth)
* 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)? and EXEC? does it makes sense to have EXEC
without READ and/or WRITE?
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)?
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?
Is the secure cache protected against the ComponentRegistry? I meant, it
is possible to do cache.getAdvancedCache().getDataContainer().clear()
and skip any authentication?
* 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.
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
in the SecureCache level so any component in Infinispan would have
access to the plain object. Also I wouldn't allow the user to choose to
encrypt only to persistence. In addition, how are we going to manage the
encryption keys? If a key is leaked are we going to support the
re-encryption with a new key? Is it possible to choose different keys
per user/type of data?
* 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?
* 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"
Cheers,
Pedro
On 11/22/2013 01:05 PM, Tristan Tarrant wrote:
Hi all,
I've published an ongoing draft of how we should implement Security in
Infinispan.
https://github.com/infinispan/infinispan/wiki/Security
There are still gaps in there, but I'd like your comments early :)
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:57 p.m.
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
4:11 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:51 p.m.
On 11/25/2013 04:11 PM, Pedro Ruivo wrote:
I was questioning about having EXEC without any other permission... What
a user/role can do only with EXEC?
Nothing. You need EXEC to be able to launch a
distexec/mapreduce, and
then you need whichever extra perms you need on top of that.
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?
Because a bulk operation (potentially)
requires far more resources. The
reasoning is the same as above: BULK needs to be combined with READ
and/or WRITE to be useful.
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)
Not explicitly. That falls in the scope of what the custom security
interceptor should do. While the idea of fs-like permissions with owner,
group, etc sounds cool, I'd leave that as a user implementation detail.
We just provide the hooks.
Tristan
3860
days inactive
3863
days old
infinispan-dev@lists.jboss.org
4 comments
2 participants
participants (2)
-
Pedro Ruivo -
Tristan Tarrant