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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> -- >> Manik Surtani >> manik(a)jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev