Is there any performance numbers for infinispan? What kind of response times would be required from secure version and what they are now etc?
On 02/09/11 13:31, Pete Muir wrote: > 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@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 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev