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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to