Mailing-List: contact commits-help@geode.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.incubator.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: rvs@apache.org
To: commits@geode.incubator.apache.org
Date: Fri, 30 Sep 2016 00:33:41 -0000
Message-Id: <f455c5f106b14c89ba82f0a92cc0fed2@git.apache.org>
In-Reply-To: <2b89ce6a4ffc4a24b0b200ff5e4148ba@git.apache.org>
References: <2b89ce6a4ffc4a24b0b200ff5e4148ba@git.apache.org>
Subject: [34/50] [abbrv] incubator-geode git commit: Incomplete update of
 setting credentials for authentication. [#130304427]
archived-at: Fri, 30 Sep 2016 00:33:18 -0000

Incomplete update of setting credentials for authentication.
[#130304427]


Project: http://git-wip-us.apache.org/repos/asf/incubator-geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-geode/commit/b9e16c0d
Tree: http://git-wip-us.apache.org/repos/asf/incubator-geode/tree/b9e16c0d
Diff: http://git-wip-us.apache.org/repos/asf/incubator-geode/diff/b9e16c0d

Branch: refs/staging/docs-grant1
Commit: b9e16c0dff53236654806877aee5e1bfb1518088
Parents: b40485b
Author: Karen Miller <kmiller@pivotal.io>
Authored: Wed Sep 14 16:34:40 2016 -0700
Committer: Karen Miller <kmiller@pivotal.io>
Committed: Wed Sep 14 16:34:40 2016 -0700

----------------------------------------------------------------------
 .../implementing_authentication.html.md.erb     | 87 +++++++++++++++++++-
 managing/security/security-audit.html.md.erb    |  2 +-
 2 files changed, 85 insertions(+), 4 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/b9e16c0d/managing/security/implementing_authentication.html.md.erb
----------------------------------------------------------------------
diff --git a/managing/security/implementing_authentication.html.md.erb b/managing/security/implementing_authentication.html.md.erb
index c238be9..98b5505 100644
--- a/managing/security/implementing_authentication.html.md.erb
+++ b/managing/security/implementing_authentication.html.md.erb
@@ -10,15 +10,96 @@ All components use the same authentication mechanism.
 
 When a component initiates a connection to the distributed system,
 the `SecurityManager.authenticate` method is invoked.
-The component provides credentials in the form of `Properties`,
-which are passed to the `authenticate` method.
+The component provides its credentials in the form of properties
+as a parameter to the `authenticate` method.
+The credential is presumed to be the two properties:
+`security-username` and `security-password`.
 The `authenticate` method is expected to either return an object
 representing a principal or throw an `AuthenticationFailedException`.
 
+A well-designed `authenticate` method will have or will have a way of
+obtaining a set of known user and password pairs that can be compared
+to the credential presented.
+
+## How a Server Sets Its Credential
+
+In order to connect with a locator that does authentication,
+a server will need to set its credential, composed of the two properties
+`security-username` and `security-password`.
+There are two ways of accomplishing this:
+
+- Set the `security-username` and `security-password` in the server's
+`gfsecurity.properties` file that will be read upon server start up,
+as in the example
+
+     ``` pre
+     security-username=admin
+     security-password=xyz1234
+     ```
+The user name and password are stored in the clear, so the
+`gfsecurity.properties` file must be protected by restricting access with
+file system permissions.
+
+- Implement the `getCredentials` method of the `AuthInitialize` interface
+for the server.
+This callback's location is defined in the property `security-peer-auth-init`,
+as in the example
+
+     ``` pre
+     security-peer-auth-init=com.example.security.MyAuthInitialize
+     ```
+The implementation of `getCredentials` may then acquire values for
+the properties `security-username` and `security-password` in whatever way
+it wishes.
+It might look up values in a database or another external resource.
+
+## How a Cache Client Sets Its Credential
+
+In order to connect with a locator or a server that does authentication,
+a client will need to set its credential, composed of the two properties
+`security-username` and `security-password`.
+There are two ways of accomplishing this:
+
+- Set the `security-username` and `security-password` in the client's
+`gfsecurity.properties` file that will be read upon client start up,
+as in the example
+
+     ``` pre
+     security-username=webclient
+     security-password=xyz1234
+     ```
+The user name and password are stored in the clear, so the
+`gfsecurity.properties` file must be protected by restricting access with
+file system permissions.
+
+- Implement the `getCredentials` method of the `AuthInitialize` interface
+for the client.
+This callback's location is defined in the property `security-client-auth-init`,
+as in the example
+
+     ``` pre
+     security-client-auth-init=com.example.security.ClientAuthInitialize
+     ```
+The implementation of `getCredentials` may then acquire values for
+the properties `security-username` and `security-password` in whatever way
+it wishes.
+It might look up values in a database or another external resource,
+or it might prompt for values.
+
+## How Other Components Set Their Credentials
+
+gfsh prompts upon `gfsh connect`.
+
+Pulse prompts upon start up.
+
+Components connecting via the REST API do something.
+
+
 
 ## Implement SecurityManager Interface
 
-Complete these items to implement authentication.
+Complete these items to implement authentication done by either a
+locator or a server.
 
 - Decide upon an authentication algorithm.
 The [Authentication Example](authentication_examples.html)

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/b9e16c0d/managing/security/security-audit.html.md.erb
----------------------------------------------------------------------
diff --git a/managing/security/security-audit.html.md.erb b/managing/security/security-audit.html.md.erb
index cec5e31..f35a29a 100644
--- a/managing/security/security-audit.html.md.erb
+++ b/managing/security/security-audit.html.md.erb
@@ -24,7 +24,7 @@ These configuration files should be readable and writeable *only* by the dedicat
 -   `gemfire.properties`
 -   `cache.xml`
 -   `gfsecurity.properties`
-    **Note:** A default `gfsecurity.properties` is not provided in the `defaultConfigs` directory. If you choose to use this properties file, you must create it manually. See [Where to Place Security Settings](implementing_security.html) for more information.
+    A default `gfsecurity.properties` is not provided in the `defaultConfigs` directory. If you choose to use this properties file, you must create it manually. A clear text user name and associated clear text password may be in this file for authentication purposes. The file system's access rights are relied upon to protect this sensitive information.
 
 The default location of the `gemfire.properties` and `cache.xml` configuration files is the `defaultConfigs` child directory of the main installation directory.