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) >
