[infinispan-dev] Infinispan Security #1: Authorization
More gripping than a gripping spy novel: http://blog.infinispan.org/2014/04/infinispan-security-1-authorization.html Fortunately you don't need a valid javax.security.auth.Subject to be able to read it :) Tristan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Security
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Security
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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Security
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Security
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 infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan security?
On 11 Sep 2011, at 16:40, Joni Hahkala wrote: On 07/09/2011 18:04, Manik Surtani wrote: On 2 Sep 2011, at 13:04, Joni Hahkala wrote: Is there any performance numbers for infinispan? What kind of response times would be required from secure version and what they are now etc? No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs. What sort of factors do you envisage with the approaches you outlined below? For ssl, you would have the problem of the handshake, you have two request-response cycles before you can even start to send the actual data. So, with anything else than intra cluster networking, you get bitten by the network latency. You can resume old ssl sessions, which save one request-response cycle, or you can keep the sockets open, and only do the handshake once, but at least keeping the sockets open doesn't scale so far. Then there is also the certificate checking, but that shouln't be that big of an issue unless you want to go for ultimate speed. Well, for inter-node traffic, this could be a problem since there will be a lot of chatter. And if we need to perform a handshake each time, that will kill performance. Unless, as you say, persistent connections can be maintained. In which case your real overhead is then just the encryption and signing. With everything there is the overhead of encryption and possibly the signing, but that shouldn't be such a big slowdown. The Seam framework seems to be more of user authentication, and would probably be good for managing the authorization information. But for authentication between the nodes and clients maybe keys would be better, kind of like ssh is doing. Cheers, Joni -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan security?
On 07/09/2011 18:04, Manik Surtani wrote: On 2 Sep 2011, at 13:04, Joni Hahkala wrote: Is there any performance numbers for infinispan? What kind of response times would be required from secure version and what they are now etc? No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs. What sort of factors do you envisage with the approaches you outlined below? For ssl, you would have the problem of the handshake, you have two request-response cycles before you can even start to send the actual data. So, with anything else than intra cluster networking, you get bitten by the network latency. You can resume old ssl sessions, which save one request-response cycle, or you can keep the sockets open, and only do the handshake once, but at least keeping the sockets open doesn't scale so far. Then there is also the certificate checking, but that shouln't be that big of an issue unless you want to go for ultimate speed. With everything there is the overhead of encryption and possibly the signing, but that shouldn't be such a big slowdown. The Seam framework seems to be more of user authentication, and would probably be good for managing the authorization information. But for authentication between the nodes and clients maybe keys would be better, kind of like ssh is doing. Cheers, Joni -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan security?
On 2 Sep 2011, at 13:04, Joni Hahkala wrote: Is there any performance numbers for infinispan? What kind of response times would be required from secure version and what they are now etc? No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs. What sort of factors do you envisage with the approaches you outlined below? -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan security?
Hi, Just a couple of ideas fron the top of my head. Sorry for the long mail, your mail covers a lot of things. :) the easiest off the shelf solution of course is SSL everything. But this would probably have some significant performance hit, even with mostly keep-alive connections. Also there would be the overhead of getting a certificate from some certificate authority whenever a new service instance (VM) is created. In this system the parts you mention would be covered by: 1) wire encrytion - SSL does this 2) inter-node comm authn - could use the host cert to authenticate to other services. Somebody would need to add the nodes to the ACL and distribute it or distribute the addition message. 3) remote client authn - the remote clients are usually services too, right? then they would probably also have a host certificate available and could use that for authentication. Somebody would need to add the clients to the ACLs. 4) in-VM authentication - would this be really necessary? Separating the services into different user accounts and then using authentication when they talk to eachother would add security, and in principle is a good thing, but careful cost-benefit analysis should be done. Probably something to keep in mind, plan and implement later? 5) ACLs for data - entire named cache level, yes definitely should do. Individual entries or key patterns: this is a bit tricky, the performance hit and need should be evaluated. Could be easier to just deploy another pool of infinispan servers than partition the keys by ACLs. The fine grained access to the data is also often pretty application specific, for example in facebook the privacy controls etc seem to change every other month. So, the fine grained access could be better left to the applications? Do you have some use case in mind? I would also add: 6) authorization in general - ACLs probably, but who manages these? For example automatic provisioning of additional servers when load increases could be a bit complicated. (obtain certificate, put into the server, add to the ACLs - by gossip?) Another, probably more performant, flexible and interesting way would be to just use encryption keys and just send encrypted messages allowing more asynchronous kind of communication, more flexible node provisioning etc. In this system the points would be as follows: 1) wire encrytion - each message is encrypted. 2) inter-node comm authn - each host would have a key for encryption and authentication to other services (created during creation of the service). Somebody would need to add the keys to the ACL and distribute it or distribute the addition message. 3) remote client authn - remote clients would have keys too (generated like ssh keys at server creation). Somebody would need to add the client keys to the ACLs. 4) in-VM authentication - same as above. 5) ACLs for data - same as above 6) authorization - same as above, but no need to obtain certificates, just generate a key and add it to the ACLs. Then there is the question whether the data stored in the infinispan even needs to be cleartext. AFAIK it's just a data blob and thus could be encrypted data. This way only the clients with proper encryption keys could see the actual data and in case of break-in in the infinispan the loss would be less. Cheers, Joni On 31/08/11 10:57, Manik Surtani wrote: Hi Joni There are no plans as such at this stage, however we realise this is an area we'd like to address. Specifically, what is interesting to me is: * Encrypting wire protocols: both inter-node communication (JGroups) as well as client/server comms (mainly Hot Rod) * Authentication for inter-node comms (JGroups) * Authentication for remote client connections (mainly Hot Rod again) * Authentication for in-VM connections (via embedded API) * ACLs for actual data. Perhaps read/write/update/delete permissions. Haven't thought too hard about granularity here (individual entries, entire named caches, or even a pattern of keys). So fairly hazy at this stage, perhaps with your background in grid security you could propose something? :-) Cheers Manik PS: cc'ing Darran Lofthouse who may have an opinion here to share as well. :) On 22 Aug 2011, at 15:33, Joni Hahkala wrote: Hi, I was reading and watching presentations of Infinispan and it seems that currently it is intended for use in secure environment, like data center behind a firewall with other datacenters connected through secure links, if I understood correctly. But deploying it in more open environment, e.g. public cloud, could pose security risks. Manik said in a presentation that the underlying Jgroups uses certificates (or can be configured to use), and I would assume SSL. So, there is at least some security in the Infinispan joins, leaves etc. Manik also told that there has been some talk/plans already about the security in general. I would be interested in hearing about
Re: [infinispan-dev] Infinispan security?
Regarding fine grained security it might be interesting to see if we can't leverage the work Shane has done with Seam Security 3, as it has a lot of parallels. I'm not sure how separate the Seam Security model is from JPA? On 2 Sep 2011, at 11:01, Joni Hahkala wrote: Hi, Just a couple of ideas fron the top of my head. Sorry for the long mail, your mail covers a lot of things. :) the easiest off the shelf solution of course is SSL everything. But this would probably have some significant performance hit, even with mostly keep-alive connections. Also there would be the overhead of getting a certificate from some certificate authority whenever a new service instance (VM) is created. In this system the parts you mention would be covered by: 1) wire encrytion - SSL does this 2) inter-node comm authn - could use the host cert to authenticate to other services. Somebody would need to add the nodes to the ACL and distribute it or distribute the addition message. 3) remote client authn - the remote clients are usually services too, right? then they would probably also have a host certificate available and could use that for authentication. Somebody would need to add the clients to the ACLs. 4) in-VM authentication - would this be really necessary? Separating the services into different user accounts and then using authentication when they talk to eachother would add security, and in principle is a good thing, but careful cost-benefit analysis should be done. Probably something to keep in mind, plan and implement later? 5) ACLs for data - entire named cache level, yes definitely should do. Individual entries or key patterns: this is a bit tricky, the performance hit and need should be evaluated. Could be easier to just deploy another pool of infinispan servers than partition the keys by ACLs. The fine grained access to the data is also often pretty application specific, for example in facebook the privacy controls etc seem to change every other month. So, the fine grained access could be better left to the applications? Do you have some use case in mind? I would also add: 6) authorization in general - ACLs probably, but who manages these? For example automatic provisioning of additional servers when load increases could be a bit complicated. (obtain certificate, put into the server, add to the ACLs - by gossip?) Another, probably more performant, flexible and interesting way would be to just use encryption keys and just send encrypted messages allowing more asynchronous kind of communication, more flexible node provisioning etc. In this system the points would be as follows: 1) wire encrytion - each message is encrypted. 2) inter-node comm authn - each host would have a key for encryption and authentication to other services (created during creation of the service). Somebody would need to add the keys to the ACL and distribute it or distribute the addition message. 3) remote client authn - remote clients would have keys too (generated like ssh keys at server creation). Somebody would need to add the client keys to the ACLs. 4) in-VM authentication - same as above. 5) ACLs for data - same as above 6) authorization - same as above, but no need to obtain certificates, just generate a key and add it to the ACLs. Then there is the question whether the data stored in the infinispan even needs to be cleartext. AFAIK it's just a data blob and thus could be encrypted data. This way only the clients with proper encryption keys could see the actual data and in case of break-in in the infinispan the loss would be less. Cheers, Joni On 31/08/11 10:57, Manik Surtani wrote: Hi Joni There are no plans as such at this stage, however we realise this is an area we'd like to address. Specifically, what is interesting to me is: * Encrypting wire protocols: both inter-node communication (JGroups) as well as client/server comms (mainly Hot Rod) * Authentication for inter-node comms (JGroups) * Authentication for remote client connections (mainly Hot Rod again) * Authentication for in-VM connections (via embedded API) * ACLs for actual data. Perhaps read/write/update/delete permissions. Haven't thought too hard about granularity here (individual entries, entire named caches, or even a pattern of keys). So fairly hazy at this stage, perhaps with your background in grid security you could propose something? :-) Cheers Manik PS: cc'ing Darran Lofthouse who may have an opinion here to share as well. :) On 22 Aug 2011, at 15:33, Joni Hahkala wrote: Hi, I was reading and watching presentations of Infinispan and it seems that currently it is intended for use in secure environment, like data center behind a firewall with other datacenters connected through secure links, if I understood correctly. But deploying it in more open environment, e.g. public cloud, could pose
Re: [infinispan-dev] Infinispan security?
Hi Joni There are no plans as such at this stage, however we realise this is an area we'd like to address. Specifically, what is interesting to me is: * Encrypting wire protocols: both inter-node communication (JGroups) as well as client/server comms (mainly Hot Rod) * Authentication for inter-node comms (JGroups) * Authentication for remote client connections (mainly Hot Rod again) * Authentication for in-VM connections (via embedded API) * ACLs for actual data. Perhaps read/write/update/delete permissions. Haven't thought too hard about granularity here (individual entries, entire named caches, or even a pattern of keys). So fairly hazy at this stage, perhaps with your background in grid security you could propose something? :-) Cheers Manik PS: cc'ing Darran Lofthouse who may have an opinion here to share as well. :) On 22 Aug 2011, at 15:33, Joni Hahkala wrote: Hi, I was reading and watching presentations of Infinispan and it seems that currently it is intended for use in secure environment, like data center behind a firewall with other datacenters connected through secure links, if I understood correctly. But deploying it in more open environment, e.g. public cloud, could pose security risks. Manik said in a presentation that the underlying Jgroups uses certificates (or can be configured to use), and I would assume SSL. So, there is at least some security in the Infinispan joins, leaves etc. Manik also told that there has been some talk/plans already about the security in general. I would be interested in hearing about these plans for security and to see if there is possibilities for cooperation. I'm currently searching for a PhD subject, I have background in grid security, and this work sounds like it could be useful and interesting. Cheers, Joni ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Infinispan security?
Hi, I was reading and watching presentations of Infinispan and it seems that currently it is intended for use in secure environment, like data center behind a firewall with other datacenters connected through secure links, if I understood correctly. But deploying it in more open environment, e.g. public cloud, could pose security risks. Manik said in a presentation that the underlying Jgroups uses certificates (or can be configured to use), and I would assume SSL. So, there is at least some security in the Infinispan joins, leaves etc. Manik also told that there has been some talk/plans already about the security in general. I would be interested in hearing about these plans for security and to see if there is possibilities for cooperation. I'm currently searching for a PhD subject, I have background in grid security, and this work sounds like it could be useful and interesting. Cheers, Joni ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
