Cool! I agree with this completely. Wasn't clear to me in the earlier
thread that we were keeping the thoughts separate.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771

On Fri, Sep 9, 2016 at 1:06 PM, John Blum <jb...@pivotal.io> wrote:

> I agree with Udo here.  Securing the channel between component/services has
> really very little to do with Authentication/Authorization, and by
> "Authentication", I mean in the user-centric sense, not the SSL "trusted"
> sense (with "trusted" keys and such).
>
> Whether a user can or cannot do something (in other words, is "authorized",
> or allowed to invoke an action, given an ACL) is a function of the action
> being performed and the privileges/rights that a user has been granted.
> That is independent of whether or not the channel has been secured.
>
> I also agree with Kirk that HTTP should perhaps be renamed to WEB.
>
> Finally, while SSL is usually a cause to reboot the system, Auth has no
> such restrictions.  I could easily change Auth credentials of a user (e.g.
> revoke privileges) at runtime.
>
> My $0.02,
> -John
>
>
> On Fri, Sep 9, 2016 at 10:00 AM, Michael Stolz <mst...@pivotal.io> wrote:
>
> > In a pure world I would go for all or nothing, but I always worry about
> the
> > upgrade path. If I have to redeploy and restart EVERYTHING around the
> whole
> > world simultaneously, it's a non-starter.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: 631-835-4771
> >
> > On Fri, Sep 9, 2016 at 12:51 PM, Anthony Baker <aba...@pivotal.io>
> wrote:
> >
> > > Mike, I was suggesting ON | OFF only for RBAC security, not for SSL
> > > configuration.  Any thoughts on that?
> > >
> > > Anthony
> > >
> > > > On Sep 9, 2016, at 9:44 AM, Michael Stolz <mst...@pivotal.io> wrote:
> > > >
> > > > I think a reason that we might need to be less than all-or-nothing is
> > for
> > > > at least these two situations:
> > > >
> > > > 1. a user who started out with SSL disabled, and now wants to enable
> > it,
> > > > but can't take a full global outage, so needs to get it enabled for
> the
> > > WAN
> > > > first, and then for server-to-server and then for client/server.
> > > >
> > > > 2. SSL enabled over the WAN because that is not a trusted network,
> but
> > > they
> > > > can live without SSL for the server/server and client/server
> > connections
> > > > because they ARE in a trusted network and they don't need to pay the
> > > > overhead for SSL on those links.
> > > >
> > > > There are probably other scenarios as well, but these are the two
> that
> > > come
> > > > to mind quickly.
> > > >
> > > >
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer, GemFire Product Manager
> > > > Mobile: 631-835-4771
> > > >
> > > > On Fri, Sep 9, 2016 at 12:05 PM, Jinmei Liao <jil...@pivotal.io>
> > wrote:
> > > >
> > > >> That is my original thought as well. If we are protecting resources
> > > >> (CLUSTER and DATA), it should be protected no matter which way user
> is
> > > >> trying to access it. I guess I'll leave this to the PMs to decide.
> > > >>
> > > >> On Thu, Sep 8, 2016 at 7:37 PM, Anthony Baker <aba...@pivotal.io>
> > > wrote:
> > > >>
> > > >>> Udo, Kirk - this makes sense and thanks for the discussion to help
> > > >> clarify
> > > >>> the issue.
> > > >>>
> > > >>> Regarding GEODE-1648, does it make sense to do at all?  That is,
> what
> > > if
> > > >>> role-based access control is either ON | OFF instead of per
> > component.
> > > >> If
> > > >>> we allow disabling RBAC for certain components, wouldn’t that make
> it
> > > >>> possible to create a backdoor?  Could we start with a binary option
> > and
> > > >>> enable more granular control when requested by users?
> > > >>>
> > > >>> Anthony
> > > >>>
> > > >>>> On Sep 8, 2016, at 4:11 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > > >>>>
> > > >>>> +1 overall with some feedback...
> > > >>>>
> > > >>>> 1) I think the list is reasonable with a few nitpicks below
> > > >>>>
> > > >>>> 2) If these are Channels and not Components, then I would probably
> > > name
> > > >>> it
> > > >>>> SecurableChannels or SecurableCommunicationChannels or whatever.
> > > >>>>
> > > >>>> 3) I'd prefer HTTP be renamed to Web or other non-protocol word --
> > > HTTP
> > > >>> is
> > > >>>> a protocol and the names of the other channels are conceptual
> > channels
> > > >>>> rather than a protocol (the others use TCP/IP or RMI but we don't
> > > label
> > > >>>> them as such). Or am I missing something here?
> > > >>>>
> > > >>>> 4) JMX is probably ok. Currently we are using (and securing) JMX
> > over
> > > >> RMI
> > > >>>> (javax.management.remote.rmi.RMIConnectorServer). There are other
> > > >>>> connectors for JMX including HTTP (ex: mx4j.tools.adaptor.http.
> > > >>> HttpAdaptor)
> > > >>>> and SNMP (ex: com.sun.jmx.snmp.daemon.SnmpAdaptorServer). We only
> > > need
> > > >>> JMX
> > > >>>> over RMI for now, but would we add those others as new enums to
> > > >>>> SecurableChannels later if we add anything like that to Geode? Or
> > > would
> > > >>> we
> > > >>>> try to group those all together under the name JMX? Or decide when
> > the
> > > >>> time
> > > >>>> comes?
> > > >>>>
> > > >>>> I think we should try to steer away from being overly controlled
> by
> > > >> specs
> > > >>>> especially for reasonable changes. We all follow agile process,
> so a
> > > >>>> decision made one iteration could easily be undone or changed in
> the
> > > >> next
> > > >>>> iteration and most of us are following weekly iterations.
> > > >>>>
> > > >>>> After a release anything exposed in a User API is very difficult
> to
> > > >>> change
> > > >>>> due to backwards compatibility constraints. I think we should be
> > much
> > > >>> more
> > > >>>> careful with User APIs in Geode going forward to avoid some of the
> > > >>> problems
> > > >>>> we have with pre-existing Geode User APIs that we inherited.
> > > >>>>
> > > >>>> -Kirk
> > > >>>>
> > > >>>> On Thu, Sep 8, 2016 at 2:07 PM, Udo Kohlmeyer <
> > ukohlme...@pivotal.io>
> > > >>> wrote:
> > > >>>>
> > > >>>>> As GEODE-420 deals with SSL comms configuration and GEODE-1648
> with
> > > >>>>> Authentication&Authorization I think we need to be careful in
> what
> > is
> > > >>>>> feasible and what is logical.
> > > >>>>>
> > > >>>>> For SSL comms it was decided that the following components are
> > > >> relevant
> > > >>>>> [1] <https://cwiki.apache.org/confluence/display/GEODE/Revised+S
> > > >>>>> SL+properties>:
> > > >>>>>
> > > >>>>> * Locator => The comms channel between Locators + the initial
> comms
> > > >>>>>  channel between clients and locator
> > > >>>>> * Cluster => Internode comms channel (peer to peer)
> > > >>>>> * Server => Client-server comms channel
> > > >>>>> * Gateway => Comms channel between WAN Gateway senders/receivers
> > > >>>>> * HTTP => Any HTTP comms. incl REST and Pulse
> > > >>>>> * JMX => Any JMX comms
> > > >>>>>
> > > >>>>> These components were selected as they seem to be logical
> > boundaries
> > > >> and
> > > >>>>> communication interfaces.
> > > >>>>>
> > > >>>>> I think the specialization of HTTP, for
> > Authentication&Authorization
> > > >> are
> > > >>>>> functions of those interfaces:
> > > >>>>>
> > > >>>>> * REST-admin
> > > >>>>> * REST-dev
> > > >>>>> * Pulse
> > > >>>>>
> > > >>>>> I think that comms and functions exposed by those comms should
> not
> > be
> > > >>>>> mixed. I think that securing the comms channel is a factor of
> > > "trust".
> > > >>> Do I
> > > >>>>> implicitly trust the interface/system that I am connected to or
> are
> > > >>>>> connecting to.
> > > >>>>>
> > > >>>>> I think concepts like "management" is a concept in function. Do I
> > > >> allow
> > > >>> a
> > > >>>>> user to access admin API's? The function of management should not
> > > >>> determine
> > > >>>>> if a system trusts another systems connection. When a new comms
> > > >>> interface
> > > >>>>> is added (say messaging), we want to be able to trust that comms
> > > >>> channel.
> > > >>>>> The "management" function should still work regardless of
> > interface,
> > > >> be
> > > >>> it
> > > >>>>> jmx,http/rest,prop tcp,messaging.
> > > >>>>>
> > > >>>>> --Udo
> > > >>>>>
> > > >>>>> [1]: https://cwiki.apache.org/confluence/display/GEODE/
> Revised+SS
> > > >>>>> L+properties
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On 9/09/2016 5:49 AM, Swapnil Bawaskar wrote:
> > > >>>>>
> > > >>>>>> GEODE-1648 and GEODE-420 are both trying to add geode properties
> > to
> > > >>> secure
> > > >>>>>> only some components.
> > > >>>>>> GEODE-1648 is intending to add a property named
> > > >>>>>> "security-enabled-components" that will allow users to turn off
> > > >>>>>> authentication/authorization for some components
> > > >>>>>> GEODE-420 is intending to add a property named
> > > >> "ssl-enabled-components"
> > > >>>>>> that will allow users to turn off ssl. for either client/server,
> > > >>>>>> peer-to-peer or wan communication.
> > > >>>>>>
> > > >>>>>> Since both deal with security, I think we should have the same
> > list
> > > >> of
> > > >>>>>> components for these new geode properties. Intent of this thread
> > is
> > > >> to
> > > >>>>>> arrive at a consensus on what these components are.
> > > >>>>>>
> > > >>>>>> I would like to propose the following components:
> > > >>>>>> Cluster => stands for peer-to-peer
> > > >>>>>> Server => client/server and developer rest API
> > > >>>>>> WAN => gateway sender/receiver
> > > >>>>>> Management => jmx, admin-rest, pulse
> > > >>>>>>
> > > >>>>>> Thanks!
> > > >>>>>> Swapnil.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >>
> > > >> Jinmei
> > > >>
> > >
> > >
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Reply via email to