[infinispan-dev] Hot Rod secured by default

Gustavo Fernandes gustavo at infinispan.org
Thu Mar 30 11:57:28 EDT 2017


On Thu, Mar 30, 2017 at 4:31 PM, Dennis Reed <dereed at redhat.com> 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 certificates,
keystores and trustores is overkill IMO.


>
> -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 that we think it would
> turn users away, that's a usability problem that needs to be fixed.
>
> -Dennis
>
>
> On 03/30/2017 09:29 AM, Tristan Tarrant wrote:
> > 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.
> >
> > Tristan
> >
> > On 30/03/2017 14:54, Sebastian Laskawiec wrote:
> >> 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 localhost/loopback and protected when
> >> calling from the outside world.
> >>
> >> On Thu, Mar 30, 2017 at 2:39 PM Tristan Tarrant <ttarrant at redhat.com
> >> <mailto:ttarrant at redhat.com>> 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
> >>     --
> >>     Tristan Tarrant
> >>     Infinispan Lead
> >>     JBoss, a division of Red Hat
> >>     _______________________________________________
> >>     infinispan-dev mailing list
> >>     infinispan-dev at lists.jboss.org <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170330/0926893c/attachment.html 


More information about the infinispan-dev mailing list