You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by rv...@apache.org on 2016/09/30 00:33:34 UTC

[27/50] [abbrv] incubator-geode git commit: Rewrite the security overview section [#130068769]

Rewrite the security overview section [#130068769]


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

Branch: refs/staging/docs-grant1
Commit: d4c43d36c9e107e1fd905b89d83d6ab2fbda9c57
Parents: 06b71c9
Author: Karen Miller <km...@pivotal.io>
Authored: Fri Sep 9 15:18:19 2016 -0700
Committer: Karen Miller <km...@pivotal.io>
Committed: Fri Sep 9 15:18:19 2016 -0700

----------------------------------------------------------------------
 managing/security/chapter_overview.html.md.erb  |  9 +-
 .../security/implementing_security.html.md.erb  | 92 ++++++++++----------
 2 files changed, 46 insertions(+), 55 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/d4c43d36/managing/security/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/managing/security/chapter_overview.html.md.erb b/managing/security/chapter_overview.html.md.erb
index 8b8ca63..88df5d8 100644
--- a/managing/security/chapter_overview.html.md.erb
+++ b/managing/security/chapter_overview.html.md.erb
@@ -4,14 +4,9 @@ title:  Security
 
 The security framework permits authentication of connecting components and authorization of operations for all communicating components of the distributed system.
 
--   **[Security Implementation Overview](../../managing/security/implementing_security.html)**
+-   **[Security Implementation Introduction and Overview](../../managing/security/implementing_security.html)**
 
-    Apache Geode can authenticate peer system members and clients. It can also authorize cache operations on a server from clients.
-
--   **[Security Features](../../managing/security/security_intro.html)**
-
-    Encryption, SSL secure communication, authentication, and authorization 
-features help to secure the distributed system.
+    Encryption, SSL secure communication, authentication, and authorization help to secure the distributed system.
 
 -   **[Security Detail Considerations](../../managing/security/security_audit_overview.html)**
 

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/d4c43d36/managing/security/implementing_security.html.md.erb
----------------------------------------------------------------------
diff --git a/managing/security/implementing_security.html.md.erb b/managing/security/implementing_security.html.md.erb
index b8122e5..4400af3 100644
--- a/managing/security/implementing_security.html.md.erb
+++ b/managing/security/implementing_security.html.md.erb
@@ -1,67 +1,63 @@
 ---
-title:  Security Implementation Overview
+title:  Security Implementation Introduction and Overview
 ---
 
-Apache Geode can authenticate system members, clients, and other system
-entities. It can also individually authorize cache operations 
-for those various entities.
+## Security Features
 
+Encryption, SSL secure communication, authentication, and authorization 
+features help to secure the distributed system.
 
-## <a id="implementing_security__section_79F6CF928E764CA294D466D0CB2E5FAC" class="no-quick-link"></a>An overview of How it all Works##
+Security features include:
 
-The security of a distributed system can be greatly enhanced by
-authenticating all system participants.
-This verifies the identity of the participants,
-gaining control over participation.
+-   **A single security interface for all components**. The single
+authentication and authorization mechanism simplifies the security
+implementation.
+It views and interacts with all components in a consistent manner. 
+-   **System-wide role-based access control**.
+Roles regiment authorized operations requested by the various components.
+-   **SSL communication**. Allows configuration of connections to be 
+SSL-based, rather than plain socket connections.
+You can enable SSL separately for peer-to-peer, client, JMX, gateway senders and receivers, and HTTP connections.
+-   **Post processing of region data**. Return values for operations that
+return region values may be altered, permitting the filtering of returned data.
+
+## Overview
+
+An authentication and authorization mechanism forms the core of
+the internal security of the distributed system.
+Communications may be further protected by enabling SSL for
+data in transit.
+
+Authentication verifies the identity of communicating components,
+leading to control over participation.
 The variety of participants include peer members, cache servers,
 clients, originators of JMX operations, Pulse,
-gateway receivers representing WAN members of the system,
+gateway senders and receivers representing WAN members of the system,
 and commands arriving from `gfsh` on behalf of system users
 or administrators.
 
+Connection requests trigger the invocation of an authentication
+callback.
+This special-purpose callback is written as part of the application,
+and it attempts to authenticate the requester by whatever
+algorithm it chooses. 
+The result is either a returned principal representing the requester's
+authenticated identity or an exception indicating that the requester
+has not been authenticated.
+The principal becomes part of any request for operations,
+which go through the authorization process.
+
+
 Given authentication,
 isolation and access to cache data and system state can be further
-protected by implementing an authorization mechanism.
-For example, only certain system administrators might be permitted
+protected by implementing the authorization mechanism,
+also implemented as a special-purpose callback as part of the application.
+For example, the protection may be to permit only certain system administrators
 to start and stop servers. 
 The authority to do this needs to be limited to specific
 verified accounts, preventing those without the authorization. 
-An implementation of an authorization mechanism requires
-that authenticated identities accompany all requests to the system,
+An implementation of the authorization callback will require
+that an authenticate identity accompanies all requests to the system,
 and that the system maintains a representation of which identities
 are permitted to complete which actions or cache commands.
 
-## Authentication and Authorization
-
-A single interface specifies authentication and a role-based access
-control for authorizing cache operations.
-
-Configuration in the form of property identifies the implementation
-of the interface.
-Defining the property enables the authentication/authorization defined
-in the implementation.
-
-A second property lists which components the implementation applies to.
-Therefore, it is configurable which components get authenticated and
-go through an authorization step prior to doing operations.
-
-## Access Control for Authorization
-
-The `ResourcePermission` object classifies operations.
-The two main parts of the object are the `Resource` and the `Operation`.
-The `Resource` identifies a role of a component within the
-distributed system.
-There are two roles:
-
-- `CLUSTER` is an administrative role. 
-- `DATA` is a role that does operations on regions. 
-
-The `Operation` qualifies what is to be accomplished.
-There are three values:
-
-- `READ` looks at data; it does not modify anything. 
-- `WRITE` modifies data. `WRITE` does not imply `READ`.
-- `MANAGE` accesses administrative information. `MANAGE` does not imply `WRITE`.
-
-Data read and write operations may be further applied to regions
-and specific keys within regions.