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(a)redhat.com>
JBoss Performance Team