OWASP - User contributions [en]

User:Mikehfauzy

2009-10-12T12:49:27Z

Mikehfauzy:

Mike Fauzy is a Certified Information System Security Professional (CISSP) and Sr. Security Engineer with Aspect Security. He has 11 years of combined experience in Java web application development and information security during which time his clients have included government agencies and companies in the financial, manufacturing and health care industries. He has built 2 application security organizations and helped lead another. He is currently leading OWASP's ESAPI Access Control 2.0 and routinely performs code reviews, penetration tests, security architecture reviews and training.

He lives in Sacramento, CA where he enjoys swing dancing, hiking and road trips.

ESAPI Access Control

2009-03-16T04:28:47Z

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

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===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.

public class '''EchoDynaBeanPolicyParameterACR''' extends DynaBeanPolicyBaseACR {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-03-10T00:09:21Z

Mikehfauzy: /* Code Samples: */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===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.

public class '''EchoDynaBeanPolicyParameterACR''' extends DynaBeanPolicyBaseACR {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Summit

2009-02-26T21:01:17Z

Mikehfauzy: /* Summit Overview */

== Summit Overview ==

The first OWASP ESAPI Summit was held December 9-11, 2008. It was hosted by Aspect Security in their Columbia, MD office.

The following were the attendees of the Summit:

*[[User:Jeff Williams|Jeff Williams]], Aspect Security - [[ESAPI|ESAPI Project Lead]]
*[[User:Wichers|Dave Wichers]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Ron Monzillo, Sun Microsystems - [http://java.sun.com/javaee/security/ Java EE Security Architect]
*[[User:Arshan|Arshan Dabirsiaghi]], Aspect Security - [[:Category:Intrinsic_Security_Working_Group|OWASP Intrisic Security Working Group Chair]]
*[[User:Jerryhoff|Jerry Hoff]], Aspect Security
*[[User:Mikehfauzy|Mike Fauzy]], Aspect Security
*[[User:Kevin.Fealey|Kevin Fealey]], Aspect Security - [[ESAPI Swingset|ESAPI Swingset Lead]]
*[[User:Jmanico|Jim Manico]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Steve Lavenhar, Booz Allen Hamilton
*Lian Jin, Booz Allen Hamilton
*John Steven, Cigital, Technical Director
*Joel Winstead, Cigital
*Alex Smolen, Foundstone - [[.NET ESAPI | ESAPI .NET Lead]]
*Andy Miller, Lockheed Martin
*John Munsch, Lockheed Martin
*Steve Christey, MITRE - [http://cve.mitre.org CVE]/[http://cwe.mitre.org CWE] Project Lead

The following pages contain our thoughts/results from the summit.

Summary: TODO

== Links ==

* [[ESAPI Charter]]
* [[ESAPI Roadmap]]
* [[ESAPI Adoption Strategy]]
* [[ESAPI Framework Strategy]]
* [[ESAPI Assurance]]
* [[ESAPI Documentation]]
* [[ESAPI Marketing]]
* [[ESAPI Tooling]]
* [[ESAPI Static Analysis Support]]
* [[ESAPI Performance]]
* [[ESAPI Internationalization]]
* [[ESAPI Installation]]

== Design ==

* [[ESAPI API]]

== Features ==

* [[ESAPI Validation]]
* [[ESAPI Canonicalization]]
* [[ESAPI Encoding]]
* [[ESAPI Authentication]]
* [[ESAPI Session Management]]
* [[ESAPI Access Control]]
* [[ESAPI Encryption]]
* [[ESAPI Randomizer]]
* [[ESAPI Error Handling]]
* [[ESAPI Logging]]
* [[ESAPI Intrusion Detection]]
* [[ESAPI HTTP Protection]]
* [[ESAPI Utilities]]
* [[ESAPI Filters]]

__NOTOC__
[[Category:OWASP Enterprise Security API]]

ESAPI Summit

2009-02-26T21:00:12Z

Mikehfauzy: Linked Mike Fauzy to his page

== Summit Overview ==

The first OWASP ESAPI Summit was held December 9-11, 2008. It was hosted by Aspect Security in their Columbia, MD office.

The following were the attendees of the Summit:

*[[User:Jeff Williams|Jeff Williams]], Aspect Security - [[ESAPI|ESAPI Project Lead]]
*[[User:Wichers|Dave Wichers]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Ron Monzillo, Sun Microsystems - [http://java.sun.com/javaee/security/ Java EE Security Architect]
*[[User:Arshan|Arshan Dabirsiaghi]], Aspect Security - [[:Category:Intrinsic_Security_Working_Group|OWASP Intrisic Security Working Group Chair]]
*[[User:Jerryhoff|Jerry Hoff]], Aspect Security
*[[User:MikeHFauzy|Mike Fauzy]], Aspect Security
*[[User:Kevin.Fealey|Kevin Fealey]], Aspect Security - [[ESAPI Swingset|ESAPI Swingset Lead]]
*[[User:Jmanico|Jim Manico]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Steve Lavenhar, Booz Allen Hamilton
*Lian Jin, Booz Allen Hamilton
*John Steven, Cigital, Technical Director
*Joel Winstead, Cigital
*Alex Smolen, Foundstone - [[.NET ESAPI | ESAPI .NET Lead]]
*Andy Miller, Lockheed Martin
*John Munsch, Lockheed Martin
*Steve Christey, MITRE - [http://cve.mitre.org CVE]/[http://cwe.mitre.org CWE] Project Lead

The following pages contain our thoughts/results from the summit.

Summary: TODO

== Links ==

* [[ESAPI Charter]]
* [[ESAPI Roadmap]]
* [[ESAPI Adoption Strategy]]
* [[ESAPI Framework Strategy]]
* [[ESAPI Assurance]]
* [[ESAPI Documentation]]
* [[ESAPI Marketing]]
* [[ESAPI Tooling]]
* [[ESAPI Static Analysis Support]]
* [[ESAPI Performance]]
* [[ESAPI Internationalization]]
* [[ESAPI Installation]]

== Design ==

* [[ESAPI API]]

== Features ==

* [[ESAPI Validation]]
* [[ESAPI Canonicalization]]
* [[ESAPI Encoding]]
* [[ESAPI Authentication]]
* [[ESAPI Session Management]]
* [[ESAPI Access Control]]
* [[ESAPI Encryption]]
* [[ESAPI Randomizer]]
* [[ESAPI Error Handling]]
* [[ESAPI Logging]]
* [[ESAPI Intrusion Detection]]
* [[ESAPI HTTP Protection]]
* [[ESAPI Utilities]]
* [[ESAPI Filters]]

__NOTOC__
[[Category:OWASP Enterprise Security API]]

ESAPI Summit

2009-02-26T20:59:49Z

Mikehfauzy: Linked Mike Fauzy to his page

== Summit Overview ==

The first OWASP ESAPI Summit was held December 9-11, 2008. It was hosted by Aspect Security in their Columbia, MD office.

The following were the attendees of the Summit:

*[[User:Jeff Williams|Jeff Williams]], Aspect Security - [[ESAPI|ESAPI Project Lead]]
*[[User:Wichers|Dave Wichers]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Ron Monzillo, Sun Microsystems - [http://java.sun.com/javaee/security/ Java EE Security Architect]
*[[User:Arshan|Arshan Dabirsiaghi]], Aspect Security - [[:Category:Intrinsic_Security_Working_Group|OWASP Intrisic Security Working Group Chair]]
*[[User:Jerryhoff|Jerry Hoff]], Aspect Security
*[[User:MikeHFauzy|Mike Fauzy, Aspect Security
*[[User:Kevin.Fealey|Kevin Fealey]], Aspect Security - [[ESAPI Swingset|ESAPI Swingset Lead]]
*[[User:Jmanico|Jim Manico]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Steve Lavenhar, Booz Allen Hamilton
*Lian Jin, Booz Allen Hamilton
*John Steven, Cigital, Technical Director
*Joel Winstead, Cigital
*Alex Smolen, Foundstone - [[.NET ESAPI | ESAPI .NET Lead]]
*Andy Miller, Lockheed Martin
*John Munsch, Lockheed Martin
*Steve Christey, MITRE - [http://cve.mitre.org CVE]/[http://cwe.mitre.org CWE] Project Lead

The following pages contain our thoughts/results from the summit.

Summary: TODO

== Links ==

* [[ESAPI Charter]]
* [[ESAPI Roadmap]]
* [[ESAPI Adoption Strategy]]
* [[ESAPI Framework Strategy]]
* [[ESAPI Assurance]]
* [[ESAPI Documentation]]
* [[ESAPI Marketing]]
* [[ESAPI Tooling]]
* [[ESAPI Static Analysis Support]]
* [[ESAPI Performance]]
* [[ESAPI Internationalization]]
* [[ESAPI Installation]]

== Design ==

* [[ESAPI API]]

== Features ==

* [[ESAPI Validation]]
* [[ESAPI Canonicalization]]
* [[ESAPI Encoding]]
* [[ESAPI Authentication]]
* [[ESAPI Session Management]]
* [[ESAPI Access Control]]
* [[ESAPI Encryption]]
* [[ESAPI Randomizer]]
* [[ESAPI Error Handling]]
* [[ESAPI Logging]]
* [[ESAPI Intrusion Detection]]
* [[ESAPI HTTP Protection]]
* [[ESAPI Utilities]]
* [[ESAPI Filters]]

__NOTOC__
[[Category:OWASP Enterprise Security API]]

ESAPI Access Control

2009-02-26T20:53:01Z

Mikehfauzy: /* ACR: Access Control Matrix */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===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.

public class '''EchoDynaBeanPolicyParameterACR''' extends DynaBeanPolicyBaseACR {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:52:35Z

Mikehfauzy: /* ACM */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR: Access Control Matrix===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:51:46Z

Mikehfauzy: /* ACR */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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.
{| class="wikitable"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR: Access Control Matrix===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:50:29Z

Mikehfauzy: /* Policy File */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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.
{| class="wikitable"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:41:43Z

Mikehfauzy: /* Code Samples: */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 '''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.
===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.
{| class="wikitable"
|-
! !!Role1!!Role2!!Role3
|-
|'''Resource1'''||Deny ||Grant||'''SpecialCaseAccessControlRule'''
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name="'''SpecialCaseAccessControlRule'''"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.'''EchoDynaBeanPolicyParameterACR'''">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization('''invocation.getAction()''', //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule '''rule''' = (AccessControlRule)ruleMap.get('''key''');
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = '''rule'''.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:24:54Z

Mikehfauzy: /* Code Samples: */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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.
===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.
{| class="wikitable"
|-
! !!Role1!!Role2!!Role3
|-
|Resource1||Deny ||Grant||SpecialCaseAccessControlRule
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name=" SpecialCaseAccessControlRule"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.EchoDynaBeanPolicyParameterACR">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization(invocation.getAction(), //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule rule = (AccessControlRule)ruleMap.get(key);
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = rule.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:18:29Z

Mikehfauzy: /* Feature Overview */

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 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.
===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.
{| class="wikitable"
|-
! !! Role1 !! Role2 !! Role3
|-
|Resource1||Deny ||Grant ||SpecialCaseAccessControlRule
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name=" SpecialCaseAccessControlRule"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.EchoDynaBeanPolicyParameterACR">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization(invocation.getAction(), //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule rule = (AccessControlRule)ruleMap.get(key);
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = rule.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:17:19Z

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

== Feature Overview ==

TODO

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
'''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.

==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 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.
===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.
{| class="wikitable"
|-
! !! Role1 !! Role2 !! Role3
|-
|Resource1||Deny ||Grant ||SpecialCaseAccessControlRule
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name=" SpecialCaseAccessControlRule"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.EchoDynaBeanPolicyParameterACR">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization(invocation.getAction(), //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule rule = (AccessControlRule)ruleMap.get(key);
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = rule.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

ESAPI Access Control

2009-02-26T20:15:43Z

Mikehfauzy: Access Control 2.0 Inception

== Feature Overview ==

TODO

=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. 
==Current Design Goals:==
# Allow developers to implement access control rules (ACR) using arbitrary java code.
#:Benefit: Allowing arbitrary java code gives ACR developers as much flexibility to write ACRs as they do throughout the normal code base.
# Facilitate integration with frameworks to enforce ACRs automatically and default to deny access.
#:Benefit: Automatically making the call reduces developer error, because both the call will be made correctly and the developer is forced to provide the security check.
# Allow developers to call ACRs for evaluation or enforcement manually.
#:Benefit: Allowing manual calls for both uses increases flexibility and facilitates reuse for access control and flow control.
# Allow ACRs to make decisions based on arbitrary runtime parameters and deployment parameters.
#:Benefit: The policy file stores deployment parameters. Accepting an arbitrary runtime parameter allows stateless ACRs, which decreases object creation costs.
==Proposed Additional Design Goals==
The following were not in the original set of goals, but I would like us to consider whether they should be included:
# Keep the Access Control Matrix (ACM) synchronized throughout the SDLC by making the ACM specification drive the integration framework that calls the ACRs.
#:Benefit: Understanding of permissions is clearer and more accurate throughout requirements and test phases.
# Allow resource names to be grouped and ensure that ACR selection is deterministic.
#:Benefit: Grouping similar resources makes the ACM clearer and easier to manage.
# Integration with Struts 2, Struts 1, JSR 115, Spring ?.?, JBoss Seam, JBossAop, Aspect J. I’m currently using the Struts2Spring2JtaJpa quickstart for the integration tests.
==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? 
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.
==Sequence:==
IntegrationComponent -> AccessController -> ACR -> Access is granted or an AccessControlException is thrown.
# When the system starts, the ACM is read and resources are linked to an ACR.
# The IntegrationComponent (e.g. a Struts2 Interceptor) calls AccessController.enforceAuthorization(key, runtimeParameter).
# AccessController maps the key to an ACR and passes it the runtime parameters and static policy file parameters.
# The ACR executes Java code to evaluate an arbitrarily complex rule set. Note that an ACR could evaluate unusually complex role requirements by assigning it to all roles for a given resource. Also note that ACRs can delegate to other ACRs or even a rules engine.
==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 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.
===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.
{| class="wikitable"
|-
! !! Role1 !! Role2 !! Role3
|-
|Resource1||Deny ||Grant ||SpecialCaseAccessControlRule
|-
|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.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<AccessControlPolicy>
<AccessControlRules>

<AccessControlRule
name="Grant"
description="Access is always granted"
class="org.owasp.esapi.accesscontrol.AlwaysTrueACR">
</AccessControlRule>
<AccessControlRule
name="Deny"
description="Access is always denied"
class="org.owasp.esapi.accesscontrol.AlwaysFalseACR">
</AccessControlRule>

<AccessControlRule
name=" SpecialCaseAccessControlRule"
description="Access depends on the value of the policy parameter: isTrue"
class="org.owasp.esapi.accesscontrol.policy.EchoDynaBeanPolicyParameterACR">
<Parameters>
<Parameter name="isTrue" type="Boolean" value="true"/>
</Parameters>
</AccessControlRule>
</AccessControlRules>
</AccessControlPolicy>

===ACR===
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 {
/**
* @return true iff policyParameter isTrue is a Boolean set to true.
* throws ClassCastException if runtimeParameter is not a Boolean.
*/
public boolean isAuthorized(Object runtimeParameter) throws ClassCastException{
return getPolicyParameters().getBoolean("isTrue");
}
}

===IntegrationComponent===
This class is (roughly) what a framework integration using a Struts2 interceptor would look like. This is part of the framework, developers don’t implement this. However, if a developer wants to execute an ACR, they can do so as demonstrated in the intercept method.

public class AccessControlEnforcementInterceptor extends AbstractInterceptor {
public String intercept(ActionInvocation invocation) throws Exception {
ESAPI.accessController().enforceAuthorization(invocation.getAction(), //assume that getAction() returns “Resource1”
invocation.getInvocationContext()); //Note that this line may change to facilitate
//mappings between Framework Integrations and multi-purpose ACRs
return invocation.invoke();
}
}

===AccessController===
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)
throws org.owasp.esapi.errors.AccessControlException {
boolean isAuthorized = false;
try {
AccessControlRule rule = (AccessControlRule)ruleMap.get(key);
if(rule == null) {
throw new AccessControlException(
"AccessControlRule was not found for key: " + key,
"");
}
System.out.println("Enforcing Authorization Rule \"" + key + "\" Using class: " + rule.getClass().getCanonicalName());
isAuthorized = rule.isAuthorized(runtimeParameter);
} catch(Exception e) {
throw new AccessControlException("An unhandled Exception was " +
"caught, so we are recasting it as an " +
"AccessControlException.",
"",
e);
}
if(!isAuthorized) {
throw new AccessControlException("Access Denied for key: " + key +
" runtimeParameter: " + runtimeParameter, "");
}
}

User:Mikehfauzy

2009-02-26T19:43:57Z

Mikehfauzy: New page: Mike Fauzy is a CISSP and Sr. Security Engineer at Aspect Security. He has a background in JEE architecture/development, web application security testing and application security risk mana...

Mike Fauzy is a CISSP and Sr. Security Engineer at Aspect Security. He has a background in JEE architecture/development, web application security testing and application security risk management. He has built 2 application security organizations and helped lead another. He is currently leading OWASP's ESAPI Access Control 2.0.

He lives in Sacramento, CA where he enjoys swing dancing, hiking and road trips.

File:API Design.docx

2008-12-11T14:35:47Z

Mikehfauzy: uploaded a new version of "Image:API Design.docx": Completed Stateful implication.

Two strawman ideas on how the API can be designed and some of the implications to start a discussion.

File:API Design.docx

2008-12-11T14:26:39Z

Mikehfauzy: Two strawman ideas on how the API can be designed and some of the implications to start a discussion.

Two strawman ideas on how the API can be designed and some of the implications to start a discussion.