geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [19/50] [abbrv] incubator-geode git commit: Detail the authorization example [#128343939]
Date Fri, 30 Sep 2016 00:33:26 GMT
Detail the authorization example [#128343939]


Branch: refs/staging/docs-grant1
Commit: f6d9c2b9c01039c9bdfce717f11acc8498128f78
Parents: b37c19f
Author: Karen Miller <>
Authored: Wed Sep 7 12:36:19 2016 -0700
Committer: Karen Miller <>
Committed: Wed Sep 7 12:36:19 2016 -0700

 .../security/  | 137 +++++++------------
 1 file changed, 46 insertions(+), 91 deletions(-)
diff --git a/managing/security/ b/managing/security/
index e474f9e..faf2bf4 100644
--- a/managing/security/
+++ b/managing/security/
@@ -2,97 +2,52 @@
 title:  Authorization Example
-This topic discusses the authorization example provided in the product under `templates/security`
using ``, ``, and `authz6_0.dtd`.
-The security implementation of every installation is unique, so this example cannot be used
as is. This example intends to provide a starting point. Modify it to handle the implementation-specific
needs of your system.
-`XmlAuthorization` provides authorization for each region at the operation level by using
the permissions specified in an XML file. The sample implementation also shows the post-authorization
implementation for the function execution operation. For pre-operation, all the required values
are available.
-You can configure authorization for all server region operations on a per-region and per-operation
basis by using a role-based mechanism. A role can be provided with permissions to execute
operations for each region. Each principal name can be associated with a set of roles.
-Information such as the region reference, arguments, the operation being invoked, and a reference
to the cache instance can be made available to the `XmlAuthorization` callback. If an authenticated
client is not authorized to perform an operation, the operation fails with a `NotAuthorizedException`.
-## <a id="authorization_example__section_076277507223430E9455E3DE5150D656" class="no-quick-link"></a>Server
-These are the `` file (or `` file if you are creating
a special restricted access file for security configuration) settings for each server:
-``` pre
-security-authz-xml-uri=<URI of XML file>
-## <a id="authorization_example__section_85F79DD53FD7453D87DF915A91595218" class="no-quick-link"></a>XML
File Sample Settings
-The `XmlAuthorization` sample is configured through an XML file, which is described in the
`authz6_0.dtd` in the security templates directory. See the dtd for documentation about the
elements and attributes you use to configure `XmlAuthorization`. To run the example, create
an XML file following the dtd specifications.
-The user names you use should be the strings returned by the `Principal.getName` method of
the `Authenticator` configured on the server
-This topic lists an example XML file for the dtd. The example defines five roles:
-1.  `reader`
-2.  `writer`
-3.  `cacheOps`
-4.  `queryRegions`
-5.  `onRegionFunctionExecutor`
-The listing below is a sample XML file:
--   The permissions for each of the roles are described in the permission tags.
--   The `reader`, `writer`, and `cacheOps` roles have no regions mentioned, so they apply
to all regions.
--   The `queryRegions` role has permissions on `Portfolios` and `Positions` regions.
--   The role of `onRegionFunctionExecutor` can only operate on regions `secureRegion` and
`Positions`, and only with functions with ids `SecureFunction` or `OptimizationFunction`.
On the functions, `optimizeForWrite` must be `false` and `keySet` must be `KEY-0` and `KEY-1`.
+This example demonstrates the basics of an implementation of the
+`SecurityManager.authorize` method.
+The remainder of the example may be found within the Apache Geode
+source code within the
+`geode-core/src/main/java/org/apache/geode/security/templates` directory.
+Of course, the security implementation of every installation is unique,
+so this example cannot be used in a production environment,
+as the roles and permissions will not match the neeeds of any
+real distributed system. 
+This example assumes that a set of users, a set of roles
+that a user might take on within the system,
+and a mapping of users to their roles are described
+in a JSON format file.
+The roles define a set of authorized resource permissions granted
+for users in those roles.
+Code not shown here parses the file to compose a data structure
+with the information on roles and users.
+The `authorize` callback denies permission for any operation
+that does not have a principal representing the identity of the
+operation's requester.
+Given the principal, 
+the method iterates through the data structure searching for the 
+necessary permissions for the principal.
+When the necessary permission is found, 
+authorization is granted by returning the value `true`.
+If the permission is not found in the data structure,
+then the method returns `false`, denying authorization of the operation.
 ``` pre
-"-//Example Systems, Inc.//Example XML Authorization 1.0//EN"
-<role name="reader">
-  <user>reader</user>
-  <user>admin</user>
-<role name="writer">
-  <user>writer</user>
-  <user>admin</user>
-<role name="cacheOps">
-  <user>admin</user>
-<role name="queryRegions">
-  <user>query</user>
-<role name="onRegionFunctionExecutor">
-  <user>admin</user>
-<permission role="cacheOps">
-  <operation>QUERY</operation>
-  <operation>EXECUTE_CQ</operation>
-  <operation>STOP_CQ</operation>
-  <operation>CLOSE_CQ</operation>
-  <operation>REGION_CREATE</operation>
-  <operation>REGION_DESTROY</operation>
-<permission role="reader">
-  <operation>GET</operation>
-  <operation>REGISTER_INTEREST</operation>
-  <operation>UNREGISTER_INTEREST</operation>
-  <operation>KEY_SET</operation>
-  <operation>CONTAINS_KEY</operation>
-<permission role="writer">
-  <operation>PUT</operation>
-  <operation>DESTROY</operation>
-  <operation>REGION_CLEAR</operation>
-<permission role="queryRegions" regions="/Portfolios,Positions">
-  <operation>QUERY</operation>
-  <operation>EXECUTE_CQ</operation>
-  <operation>STOP_CQ</operation>
-  <operation>CLOSE_CQ</operation>
-<permission role="onRegionFunctionExecutor" regions="secureRegion,Positions">
-  <operation functionIds="SecureFunction,OptimizationFunction"
-    optimizeForWrite="false" keySet="KEY-0,KEY-1">EXECUTE_FUNCTION</operation>
+public boolean authorize(final Object principal, final ResourcePermission context) {
+    if (principal == null) return false;
+    User user = this.userNameToUser.get(principal.toString());
+    if (user == null) return false; // this user is not authorized to do anything
+    // check if the user has this permission defined in the context
+    for (Role role : this.userNameToUser.get( {
+        for (Permission permitted : role.permissions) {
+            if (permitted.implies(context)) {
+                return true;
+            }
+        }
+    }
+    return false;

View raw message