[infinispan-dev] Infinispan security?

[Pete Muir]

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