[infinispan-dev] Hot Rod secured by default

[Radim Vansa]

I don't see an example/quickstart using security on the tutorials page 
[1]. Could you provide one that would show what all would the user have 
to configure in order to do HotRod hello world?

While secure OOTB is good, I like performant OOTB. And it seems to me 
that "I need security" is something they'll probably think about when 
deploying (if they need that), and will look it up, I wouldn't like to 
see "turn off security" in the perf tuning guide. So I'd say -1 to SSL 
by default.

-1 to PLAIN authentication without encryption, that's not a safe 
default. [2]

Radim

[1] http://infinispan.org/tutorials/
[2] http://www.prokofiev.ru/prikol/pics/p12/winfirewall.jpg

On 03/30/2017 02:39 PM, Tristan Tarrant wrote:
> Let me add another item:
>
> combined with Sebastian's PR [1] we could also turn on encryption by
> default using a self-signed certificate. We would also need to have an
> easy option (i.e. a boolean, false by default) on the Hot Rod clients to
> trust all certs.
>
> This means that a Hot Rod client would need to be configured as follows:
>
> ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
> clientBuilder
>     .security()
>       .authentication()
>         .username("user").realm("realm").password("password")
>       .ssl()
>         .enable().trustAll(true);
>
> without having to manually set up callback handlers or trustmanagers.
>
> I don't think this would affect the user experience too much.
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/5036
>
> On 30/03/2017 14:25, Tristan Tarrant wrote:
>> Dear all,
>>
>> after a mini chat on IRC, I wanted to bring this to everybody's attention.
>>
>> We should make the Hot Rod endpoint require authentication in the
>> out-of-the-box configuration.
>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>> mechanism against the ApplicationRealm and require users to run the
>> add-user script.
>> This would achieve two goals:
>> - secure out-of-the-box configuration, which is always a good idea
>> - access to the "protected" schema and script caches which is prevented
>> when not on loopback on non-authenticated endpoints.
>>
>> Tristan


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team