Detail the authorization example [#128343939]
Project: http://git-wip-us.apache.org/repos/asf/incubator-geode/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-geode/commit/f6d9c2b9 Tree: http://git-wip-us.apache.org/repos/asf/incubator-geode/tree/f6d9c2b9 Diff: http://git-wip-us.apache.org/repos/asf/incubator-geode/diff/f6d9c2b9 Branch: refs/staging/docs-grant1 Commit: f6d9c2b9c01039c9bdfce717f11acc8498128f78 Parents: b37c19f Author: Karen Miller <[email protected]> Authored: Wed Sep 7 12:36:19 2016 -0700 Committer: Karen Miller <[email protected]> Committed: Wed Sep 7 12:36:19 2016 -0700 ---------------------------------------------------------------------- .../security/authorization_example.html.md.erb | 137 +++++++------------ 1 file changed, 46 insertions(+), 91 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/f6d9c2b9/managing/security/authorization_example.html.md.erb ---------------------------------------------------------------------- diff --git a/managing/security/authorization_example.html.md.erb b/managing/security/authorization_example.html.md.erb index e474f9e..faf2bf4 100644 --- a/managing/security/authorization_example.html.md.erb +++ b/managing/security/authorization_example.html.md.erb @@ -2,97 +2,52 @@ title: Authorization Example --- -This topic discusses the authorization example provided in the product under `templates/security` using `XmlAuthorization.java`, `XmlErrorHandler.java`, 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 Settings - -These are the `gemfire.properties` file (or `gfsecurity.properties` file if you are creating a special restricted access file for security configuration) settings for each server: - -``` pre -security-client-accessor=templates.security.XmlAuthorization.create -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 -<!DOCTYPE acl PUBLIC -"-//Example Systems, Inc.//Example XML Authorization 1.0//EN" -"http://www.example.com/dtd/authz6_0.dtd";> - -<acl> -<role name="reader"> - <user>reader</user> - <user>admin</user> -</role> -<role name="writer"> - <user>writer</user> - <user>admin</user> -</role> -<role name="cacheOps"> - <user>admin</user> -</role> -<role name="queryRegions"> - <user>query</user> -</role> -<role name="onRegionFunctionExecutor"> - <user>admin</user> -</role> -<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> -<permission role="reader"> - <operation>GET</operation> - <operation>REGISTER_INTEREST</operation> - <operation>UNREGISTER_INTEREST</operation> - <operation>KEY_SET</operation> - <operation>CONTAINS_KEY</operation> -</permission> -<permission role="writer"> - <operation>PUT</operation> - <operation>DESTROY</operation> - <operation>REGION_CLEAR</operation> -</permission> -<permission role="queryRegions" regions="/Portfolios,Positions"> - <operation>QUERY</operation> - <operation>EXECUTE_CQ</operation> - <operation>STOP_CQ</operation> - <operation>CLOSE_CQ</operation> -</permission> -<permission role="onRegionFunctionExecutor" regions="secureRegion,Positions"> - <operation functionIds="SecureFunction,OptimizationFunction" - optimizeForWrite="false" keySet="KEY-0,KEY-1">EXECUTE_FUNCTION</operation> -</permission> -</acl> +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(user.name).roles) { + for (Permission permitted : role.permissions) { + if (permitted.implies(context)) { + return true; + } + } + } + + return false; +} ```
