Hi John, They are documented in the docs dev branch and will be published with the next Geode release. Also, we're scheduled to donate the docs code to the project later this week, so you'll be able to see the work in dev.
Best, Joey On Mon, Sep 26, 2016 at 10:41 AM John Blum <jb...@pivotal.io> wrote: > Jinmei- > > Where are the following security-* properties documented? > > security-udp-dhalgo > > security-manager > > security-post-processor > > They certainly are not documented in the (Geode) User Docs, here > < > http://geode.docs.pivotal.io/docs/reference/topics/gemfire_properties.html > > > [1]. > > Thanks! > John > > [1] > http://geode.docs.pivotal.io/docs/reference/topics/gemfire_properties.html > > > > On Mon, Sep 26, 2016 at 8:42 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > Actually, I looked into the the config settings, these are the list of > > settings that begin with security-. SSL settings are not there. The > > security-client-* and security-peer-* are deprecated, so they don't need > to > > be in the cluster config. What about the udp-dhalgo and log-file and > > log-level? Does it hurt to put them in the cluster-config? > > > > "security-client-authenticator"; > > > > "security-client-accessor"; > > > > "security-client-accessor-pp"; > > > > "security-client-auth-init"; > > > > "security-client-dhalgo"; > > > > "security-peer-auth-init"; > > > > "security-peer-authenticator"; > > > > "security-peer-verifymember-timeout"; > > > > "security-udp-dhalgo"; > > > > "security-log-file"; > > > > "security-log-level"; > > > > "security-manager"; > > > > "security-post-processor"; > > > > > > > > > > > > > > > > On Fri, Sep 23, 2016 at 12:41 PM, Bruce Schuchardt < > bschucha...@pivotal.io > > > > > wrote: > > > > > SSL settings and the new UDP dhAlgo setting can't be in the cluster > > > config. The cluster config is received over TCP/IP so you would have > to > > > use unsecured information to retrieve the settings, and you'd have to > do > > it > > > before the cache is created. > > > > > > Does the security-manager have any role to play prior to the cache > being > > > created? For instance, is it involved in authenticating the receipt > of > > a > > > new membership view or a join request in GMSAuthenticator? If so you > > can't > > > store it in the cluster config, which is only retrieved later on during > > > cache creation. > > > > > > > > > > > > Le 9/23/2016 à 11:57 AM, Michael Stolz a écrit : > > > > > >> I am in favor of keeping the SSL thoughts separate from the RBAC > > thoughts, > > >> but I don't see any reason they couldn't share the same repository. > > >> > > >> That said though, does putting it all into the Cluster Configuration > > >> Manager (CCM) make it so that you can only have security if you are > > using > > >> CCM for configuration? > > >> > > >> > > >> -- > > >> Mike Stolz > > >> Principal Engineer, GemFire Product Manager > > >> Mobile: 631-835-4771 > > >> > > >> On Fri, Sep 23, 2016 at 1:48 PM, Jinmei Liao <jil...@pivotal.io> > wrote: > > >> > > >> Hi, All, > > >>> > > >>> I am working on this ticket: > > >>> https://issues.apache.org/jira/browse/GEODE-1659. Basically, > > currently, > > >>> any > > >>> member(locator or server) needs to specify its own security-manager > in > > >>> order to protect its data which could leads to misconfiguration and > > data > > >>> leak. So we would like to put it into the cluster configuration so > any > > >>> member who wants to join the cluster will need to apply the same > > security > > >>> measures. > > >>> > > >>> Now Here is my question, should we only put the "security-manager" > and > > >>> "security-post-processor" in the cluster config or any "security-*" > > >>> settings, which include SSL settings as well. > > >>> > > >>> Thanks! > > >>> > > >>> -- > > >>> Cheers > > >>> > > >>> Jinmei > > >>> > > >>> > > > > > > > > > -- > > Cheers > > > > Jinmei > > > > > > -- > -John > 503-504-8657 > john.blum10101 (skype) >
