I realized I've been assuming you were asking about turning on ssl authentication. Maybe you are talking about authenticating with the security manager. Either way, what Anthony said still applies - the new protocol should just use the existing properties (security-manager in that case).
-Dan On Mon, Oct 2, 2017 at 12:57 PM, John Blum <jb...@pivotal.io> wrote: > I don't mean to derail the topic at hand, but... > > On the same vain as Properties, can we also stop talking about XML? I much > prefer Properties over XML any day, especially given YAML. However, that > does not imply Properties should be added at will. Properties also > increase the "surface area" of the public API as well. > > Also, the API and XML are not on even plane; not even close. > > IMO, the API should be the primary means to configure a feature; all other > configuration options are secondary and optional (as needed). > > Therefore, given an API-first approach, the other configuration formats and > options become more apparent (providing the API was designed with the right > abstractions in the first place). > > $.0.02, > -j > > > > On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith <dsm...@pivotal.io> wrote: > >> One thing to think about - if the new protocol doesn't support two-way >> authentication maybe we should throw an exception if the user sets >> ssl-require-authentication=true? We definitely don't want to lie to >> the user and pretend that we are providing some level of security >> which we are not. >> >> I'm assuming the new protocol will also need to read the ssl-ciphers, >> ssl-protocols, ssl-keystore and ssl-truststore settings. >> >> -Dan >> >> On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker <aba...@pivotal.io> wrote: >> > Is there a need for property yet? >> > >> > The authentication-enabled question could be answered from the existing >> security properties. That ensures consistency and means a user would only >> need to set a single switch. >> > >> > If we only support a single authentication mode, we can defer adding >> configration until we need it. >> > >> > Anthony >> > >> >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan <gosulli...@apache.org> >> wrote: >> >> >> >> Currently, we have a setting for the new client protocol that controls >> >> whether authentication is required or not. We expect to expand this in >> the >> >> future, and also that there may be more configuration options for the >> >> protocol. We would like to namespace the settings for this protocol but >> >> don't really have a good name for the protocol. >> >> >> >> We're expecting to do configuration via gemfire.properties -- I hear >> that's >> >> the right place to put these things. It looks like the setting would >> take a >> >> form like `geode.new-client-protocol.authentication-mode`. "New" client >> >> protocol is not a good name because it will be outdated before long. >> It's >> >> not the only client protocol, so "client-protocol" would be misleading. >> Any >> >> other ideas? >> >> >> >> Thanks, >> >> Galen >> > >> > > > > -- > -John > john.blum10101 (skype)
