+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. >> >> >
