ESAPI Access Control - Revision history

Jmanico at 04:31, 6 November 2010

2010-11-06T04:31:15Z

Mikehfauzy: /* Outstanding Questions from the ESAPI Summit and their Answers: */

2009-03-16T04:28:47Z

‎Outstanding Questions from the ESAPI Summit and their Answers:

Mikehfauzy: /* Code Samples: */

2009-03-10T00:09:21Z

‎Code Samples:

Mikehfauzy: /* ACR: Access Control Matrix */

2009-02-26T20:53:01Z

‎ACR: Access Control Matrix

Mikehfauzy: /* ACM */

2009-02-26T20:52:35Z

‎ACM

Mikehfauzy: /* ACR */

2009-02-26T20:51:46Z

‎ACR

Mikehfauzy: /* Policy File */

2009-02-26T20:50:29Z

‎Policy File

Mikehfauzy: /* Code Samples: */

2009-02-26T20:41:43Z

‎Code Samples:

Mikehfauzy: /* Code Samples: */

2009-02-26T20:24:54Z

‎Code Samples:

Mikehfauzy: /* Feature Overview */

2009-02-26T20:18:29Z

‎Feature Overview

← Older revision		Revision as of 04:31, 6 November 2010
Line 1:		Line 1:
		+	[[Category:OWASP Enterprise Security API]]
		+
	=Access Control 2.0=		=Access Control 2.0=
	At the ESAPI summit, we discussed changing Access Control 2.0 to use the command pattern. The following are the current design goals for Access Control 2.0. Enough proof of concept development has been completed for me to believe that these goals are achievable. I’d appreciate your input as to whether they are both desirable and sufficient. Below the goals are the answers to outstanding questions, the sequence of execution and some code snippets to give a better feel for the current direction. Feedback is welcome. I’m happy to make changes.<br>		At the ESAPI summit, we discussed changing Access Control 2.0 to use the command pattern. The following are the current design goals for Access Control 2.0. Enough proof of concept development has been completed for me to believe that these goals are achievable. I’d appreciate your input as to whether they are both desirable and sufficient. Below the goals are the answers to outstanding questions, the sequence of execution and some code snippets to give a better feel for the current direction. Feedback is welcome. I’m happy to make changes.<br>

@@ Line 19: / Line 19: @@
 ==Outstanding Questions from the ESAPI Summit and their Answers:==
 '''Question''': Can the runtimeParameter AccessController.isAuthorized(“Resource”, runtimeParameter) be strongly typed in the ACR definition class? <br>
-'''Answer''': Yes. Java versions 1.5 and above can leverage Generics. Commands written for 1.4 and below will need to use Object as parameters and then cast appropriately. The current version of Access Control 2.0 is written without generics for backwards compatibility, but I plan to add generics compatible version.
+'''Answer''': Yes. Java versions 1.5 and above can leverage Generics. AccessControlRules written for 1.4 and below will need to use Object as parameters and then cast appropriately. The current version of Access Control 2.0 is written without generics for backwards compatibility, but I plan to add generics compatible version.
 ==Sequence:==

@@ Line 29: / Line 29: @@
 ==Code Samples:==
 What follows is a partial strawman implementation from some proof of concept code that I’ve been working on. Code has been removed to help focus on the critical path. I’d appreciate any feedback and I’m looking especially interested in feedback on usability from a developer’s point of view. Would this help you to implement Access Control for large projects? What can I do to make it safer and easier for developers?
-To help illustrate the mappings, I’ve used <span style="color:red">'''bold red'''</span> to represent the resource identifier and <span style="color:green">'''bold green''</span> to represent the ACR throughout the files. Only the first 3 files (ACM, Policy file and ACR) are implemented by the developer. The rest are provided by the AccessController infrastructure.
+To help illustrate the mappings, I’ve used <span style="color:red">'''bold red'''</span> to represent the resource identifier and <span style="color:green">'''bold green'''</span> to represent the ACR throughout the files. Only the first 3 files (ACM, Policy file and ACR) are implemented by the developer. The rest are provided by the AccessController infrastructure.
 ===ACM: Access Control Matrix===
 This table is (roughly) what the Access Control Matrix looks like. It would probably be a .csv file or database file and would have options to group resources using regular expressions, String.startsWith, etc. The ACM and Policy File (below) combine to define which ACR is executed by AccessController.

@@ Line 70: / Line 70: @@
   </AccessControlPolicy>
-===ACR: Access Control Matrix===
+===ACR: Access Control Rule===
 The following class is (roughly) what a simple ACR could look like. Note that the runtimeParameter can leverage generics for type safety. Developers would implement this.

@@ Line 30: / Line 30: @@
 What follows is a partial strawman implementation from some proof of concept code that I’ve been working on. Code has been removed to help focus on the critical path. I’d appreciate any feedback and I’m looking especially interested in feedback on usability from a developer’s point of view. Would this help you to implement Access Control for large projects? What can I do to make it safer and easier for developers?
 To help illustrate the mappings, I’ve used <span style="color:red">'''bold red'''</span> to represent the resource identifier and <span style="color:green">'''bold green''</span> to represent the ACR throughout the files. Only the first 3 files (ACM, Policy file and ACR) are implemented by the developer. The rest are provided by the AccessController infrastructure.
-===ACM===
+===ACM: Access Control Matrix===
 This table is (roughly) what the Access Control Matrix looks like. It would probably be a .csv file or database file and would have options to group resources using regular expressions, String.startsWith, etc. The ACM and Policy File (below) combine to define which ACR is executed by AccessController.
 {| class="wikitable"
@@ Line 40: / Line 40: @@
 |Resource2||Grant||Deny	||Deny
 |}
 ===Policy File===
 This xml file is (roughly) what the ACR definitions would look like. It handles what would normally be “footnotes” in an ACM requirements specification document. The name correlates to an ACM cell. The AccessControlRule.class specifies the Java code that will execute. The parameters are passed to the ACR at runtime. Note that this shows the default name-value pair parameter loader, but other parameter loaders (not shown) can be specified. An enhancement would be to allow ACRs to be tagged using annotations so that the Policy file isn't required.

@@ Line 29: / Line 29: @@
 ==Code Samples:==
 What follows is a partial strawman implementation from some proof of concept code that I’ve been working on. Code has been removed to help focus on the critical path. I’d appreciate any feedback and I’m looking especially interested in feedback on usability from a developer’s point of view. Would this help you to implement Access Control for large projects? What can I do to make it safer and easier for developers?
-To help illustrate the mappings, I’ve used {{fontcolor|red|bold red}} to represent the resource identifier and bold green to represent the ACR throughout the files. Only the first 3 files (ACM, Policy file and ACR) are implemented by the developer. The rest are provided by the AccessController infrastructure.
+To help illustrate the mappings, I’ve used <span style="color:red">'''bold red'''</span> to represent the resource identifier and <span style="color:green">'''bold green''</span> to represent the ACR throughout the files. Only the first 3 files (ACM, Policy file and ACR) are implemented by the developer. The rest are provided by the AccessController infrastructure.
 ===ACM===
 This table is (roughly) what the Access Control Matrix looks like. It would probably be a .csv file or database file and would have options to group resources using regular expressions, String.startsWith, etc. The ACM and Policy File (below) combine to define which ACR is executed by AccessController.
@@ Line 36: / Line 36: @@
 !         !!Role1!!Role2!!Role3
 |-
-|Resource1||Deny ||Grant||SpecialCaseAccessControlRule
+|<span style="color:red">'''Resource1'''</span>||Deny ||Grant||<span style="color:green">'''SpecialCaseAccessControlRule'''</span>
 |-
 |Resource2||Grant||Deny	||Deny
@@ Line 59: / Line 59: @@
              <!-- Developers would implement this -->
              <AccessControlRule
-                   name=" SpecialCaseAccessControlRule"
+                   name="<span style="color:green">'''SpecialCaseAccessControlRule'''</span>"
                    description="Access depends on the value of the policy parameter: isTrue"
-                   class="org.owasp.esapi.accesscontrol.policy.EchoDynaBeanPolicyParameterACR">
+                   class="org.owasp.esapi.accesscontrol.policy.<span style="color:green">'''EchoDynaBeanPolicyParameterACR'''</span>">
                    <Parameters>
                          <Parameter name="isTrue" type="Boolean" value="true"/>
@@ Line 72: / Line 72: @@
 The following class is (roughly) what a simple ACR could look like. Note that the runtimeParameter can leverage generics for type safety. Developers would implement this.
-  public class EchoDynaBeanPolicyParameterACR extends DynaBeanPolicyBaseACR {
+  public class <span style="color:green">'''EchoDynaBeanPolicyParameterACR'''</span> extends DynaBeanPolicyBaseACR {
        /**
         * @return true iff policyParameter isTrue is a Boolean set to true.
@@ Line 87: / Line 87: @@
   public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
      public String intercept(ActionInvocation invocation) throws Exception {
-           ESAPI.accessController().enforceAuthorization(invocation.getAction(), //assume that getAction() returns “Resource1”
+           ESAPI.accessController().enforceAuthorization(<span style="color:red">'''invocation.getAction()'''</span>, //assume that getAction() returns “Resource1”
                    invocation.getInvocationContext()); //Note that this line may change to facilitate
                                                        //mappings between Framework Integrations and multi-purpose ACRs
@@ Line 97: / Line 97: @@
 This class is (roughly) what the enforceAuthorization method in AccessController could look like. The key is the resource. In our example “Resource1.” This method will need to be enhanced to handle resource groups. This is part of the framework, developers don’t implement this. This doesn’t currently take the user’s role into account, but could.
-  public void enforceAuthorization(Object key, Object runtimeParameter)
+  public void enforceAuthorization(Object <span style="color:red">'''key'''</span>, Object runtimeParameter)
        throws org.owasp.esapi.errors.AccessControlException {
        boolean isAuthorized = false;
        try {
-             AccessControlRule rule = (AccessControlRule)ruleMap.get(key);
+             AccessControlRule <span style="color:green">'''rule'''</span> = (AccessControlRule)ruleMap.get(<span style="color:red">'''key'''</span>);
              if(rule == null) {
                    throw new AccessControlException(
@@ Line 108: / Line 108: @@
+             }
              System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
-             isAuthorized = rule.isAuthorized(runtimeParameter);
+             isAuthorized = <span style="color:green">'''rule'''</span>.isAuthorized(runtimeParameter);
        } catch(Exception e) {
              throw new AccessControlException("An unhandled Exception was " +

← Older revision		Revision as of 20:18, 26 February 2009
Line 1:		Line 1:
−	~~== Feature Overview ==~~
−
−	~~TODO~~
−
	=Access Control 2.0=		=Access Control 2.0=
	At the ESAPI summit, we discussed changing Access Control 2.0 to use the command pattern. The following are the current design goals for Access Control 2.0. Enough proof of concept development has been completed for me to believe that these goals are achievable. I’d appreciate your input as to whether they are both desirable and sufficient. Below the goals are the answers to outstanding questions, the sequence of execution and some code snippets to give a better feel for the current direction. Feedback is welcome. I’m happy to make changes.<br>		At the ESAPI summit, we discussed changing Access Control 2.0 to use the command pattern. The following are the current design goals for Access Control 2.0. Enough proof of concept development has been completed for me to believe that these goals are achievable. I’d appreciate your input as to whether they are both desirable and sufficient. Below the goals are the answers to outstanding questions, the sequence of execution and some code snippets to give a better feel for the current direction. Feedback is welcome. I’m happy to make changes.<br>