Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant writes: > Sorry for reviving this thread, but I want to make sure we all agree on > the following points. > > DEFAULT CONFIGURATIONS > - The endpoints MUST be secure by default (authentication MUST be > enabled and required) in all of the supplied default

Re: [infinispan-dev] Hot Rod secured by default

+1 To improve convenience, would be nice to also have some examples to configure credentials in some automated fashion; e.g. CLI scripts and an example of running them for a Maven integration test? Thanks, Sanne On 5 February 2018 at 11:02, Tristan Tarrant wrote: > Sorry

Re: [infinispan-dev] Hot Rod secured by default

Sorry for reviving this thread, but I want to make sure we all agree on the following points. DEFAULT CONFIGURATIONS - The endpoints MUST be secure by default (authentication MUST be enabled and required) in all of the supplied default configurations. - We can ship non-secure configurations,

Re: [infinispan-dev] Hot Rod secured by default

Gustavo's reply was the agreement reached. Secured by default and an easy way to use it unsecured is the best middle ground IMO. So, we've done the securing part partially, which needs to be completed by [2] (currently assigned to Tristan). More importantly, we also need to complete [3] so

Re: [infinispan-dev] Hot Rod secured by default

@Emmanuel, sure it't not a big deal, but starting fast and smooth without any trouble helps adoption. Concerning the ticket, there is already one that was acted. I can work on that, even if is assigned to Galder now. @Gustavo Yes, as I read - better - now on the security part, it is said for the

Re: [infinispan-dev] Hot Rod secured by default

Comments inlined On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti wrote: > > And then I want to go to the console, requires me to put again the > user/password. And it does not work. And I don't see how to disable > security. And I don't know what to do. And I'm like : why do I

Re: [infinispan-dev] Hot Rod secured by default

We have that discussion several times and I remember it years ago. What I've seen in onld EAP4 times is that user start a JBoss instance (which run with unsecure console by default) and secured everything they use, but forgot the console which they don't use. Finally that ends in an open door to

Re: [infinispan-dev] Hot Rod secured by default

When you deploy a RDBMS on OpenShift, it is secured by default I think and it's not a big deal. It is possible to read back secrets in OpenShift in case you forgot them. Maybe there is a way to either document that better, maybe having the same password between console and cache by default is

Re: [infinispan-dev] Hot Rod secured by default

Hi all, I came up to this thread now, at the time I did not understand what we discussed here. Let me tell you my experience of today. I want to create a vert.x application, super simple, that connects to infinispan-server. Everything in open-shift. I take an vert-x example as base, super

Re: [infinispan-dev] Hot Rod secured by default

Hi all, Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects: 1. Remove auth check in server's CacheDecodeContext. 2. Default server configuration should require

Re: [infinispan-dev] Hot Rod secured by default

That is caused by not wrapping the calls in PrivilegedActions in all the correct places and is a bug. Tristan On 19/04/2017 11:34, Sebastian Laskawiec wrote: > The proposal look ok to me. > > But I would also like to highlight one thing - it seems you can't access > secured cache properties

Re: [infinispan-dev] Hot Rod secured by default

+100 -- Galder Zamarreño Infinispan, Red Hat > On 19 Apr 2017, at 10:57, Tristan Tarrant wrote: > > Currently the "protected cache access" security is implemented as follows: > > - if authorization is enabled || client is on loopback > allow > > The first check also

Re: [infinispan-dev] Hot Rod secured by default

The proposal look ok to me. But I would also like to highlight one thing - it seems you can't access secured cache properties using CLI. This seems wrong to me (if you can invoke the cli, in 99,99% of the cases you have access to the machine, so you can do whatever you want). It also breaks

Re: [infinispan-dev] Hot Rod secured by default

Currently the "protected cache access" security is implemented as follows: - if authorization is enabled || client is on loopback allow The first check also implies that authentication needs to be in place, as the authorization checks need a valid Subject. Unfortunately authorization is

Re: [infinispan-dev] Hot Rod secured by default

Agree with Wolf. Let's keep it simple by just providing extra configuration files for dev/unsecure envs. Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 15 Apr 2017, at 12:57, Wolf Fink wrote: > > I would think a "switch" can have other impacts as you need to check it

Re: [infinispan-dev] Hot Rod secured by default

I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here So what is wrong with some configurations which are the default and secured. and a "*-dev or *-unsecure" configuration to start easy. Also this can be used in production if

Re: [infinispan-dev] Hot Rod secured by default

I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in

Re: [infinispan-dev] Hot Rod secured by default

-- Galder Zamarreño Infinispan, Red Hat > On 13 Apr 2017, at 09:50, Gustavo Fernandes wrote: > > On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño wrote: > Hi all, > > As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and >

Re: [infinispan-dev] Hot Rod secured by default

On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño wrote: > Hi all, > > As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and > Sebastian, I've created a docker image snapshot that reverts the change > stop protected caches from requiring security enabled [1].

Re: [infinispan-dev] Hot Rod secured by default

Hi all, As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1]. In other words, I've removed [2]. The reason for temporarily doing that is

Re: [infinispan-dev] Hot Rod secured by default

On Mon, Apr 3, 2017 at 1:52 PM, Sebastian Laskawiec wrote: > That's actually a very good point but it deserves separate discussion I > think. > > The point is that we get an initialized SSLEngine from WF. Then we simply > build Netty's JdkSslContext [1] (as you probably

Re: [infinispan-dev] Hot Rod secured by default

That's actually a very good point but it deserves separate discussion I think. The point is that we get an initialized SSLEngine from WF. Then we simply build Netty's JdkSslContext [1] (as you probably know, Netty uses its own SSLContext; this JdkSslContext class acts as a bridge between Netty

Re: [infinispan-dev] Hot Rod secured by default

You want to use OpenSSL with Netty: http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4 Tristan On 31/03/2017 15:55, Sebastian Laskawiec wrote: > Unfortunately TLS still slows down stuff (a lot). When I was doing tests > for the multi-tenancy router (which is based on TLS/SNI), my average

Re: [infinispan-dev] Hot Rod secured by default

Unfortunately TLS still slows down stuff (a lot). When I was doing tests for the multi-tenancy router (which is based on TLS/SNI), my average results were like this: Use-case Type Avg Error initConnectionAndPerform10KPuts SingleServerNoSsl 1034.817 14.424 initConnectionAndPerform10KPuts

Re: [infinispan-dev] Hot Rod secured by default

+1 to make the default secure. -1 SSL by default as it makes it slower and I think not most will use it -1 easy trust all certs, That sounds to me we close one door and make it possible to open another one What if we add an example configuration unsecured which can be simple copied for

Re: [infinispan-dev] Hot Rod secured by default

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

Re: [infinispan-dev] Hot Rod secured by default

On 30/03/2017 17:31, Dennis Reed wrote: > +1 to authentication and encryption by default. >This is 2017, that's how *everything* should be configured. > > -1 to making it easy to trust all certs. That negates the point of > using encryption in the first place and should really never be

Re: [infinispan-dev] Hot Rod secured by default

On Thu, Mar 30, 2017 at 4:31 PM, Dennis Reed wrote: > +1 to authentication and encryption by default. > This is 2017, that's how *everything* should be configured. > Agree, and SSL can always be turned on if needed. But enabling it by default and forcing upfront handling of

Re: [infinispan-dev] Hot Rod secured by default

+1 to authentication and encryption by default. This is 2017, that's how *everything* should be configured. -1 to making it easy to trust all certs. That negates the point of using encryption in the first place and should really never be done. If it's too hard to configure the correct way

Re: [infinispan-dev] Hot Rod secured by default

While the "unsecure" over loopback is quite tempting, I would prefer to have homogeneous behaviour with the possibility to disable security altogether for quick demos. Otherwise a developer would need to code differently for the local use case than for the remote one, causing more confusion.

Re: [infinispan-dev] Hot Rod secured by default

-1 to SSL by default On Thu, Mar 30, 2017 at 1: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

Re: [infinispan-dev] Hot Rod secured by default

I agree the security out of the box is good. But at the same time we don't want to make Infinispan harder to use for new developers. Out of the box configuration should be "good enough" to start hacking. I would propose to make all the endpoints unprotected (with authentication disabled) on

Re: [infinispan-dev] Hot Rod secured by default

+1 On Thu, Mar 30, 2017 at 1:25 PM, 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

Re: [infinispan-dev] Hot Rod secured by default

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

[infinispan-dev] Hot Rod secured by default

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