[infinispan-dev] Infinispan security?

[Joni Hahkala]

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 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev