executioncontext20091231/BranchReadMe.txt - ofbiz - Git at Google

 ExecutionContext and Security-Aware Artifacts Notes
 ---------------------------------------------------

 2010-01-20: Security-aware artifact TODOs:

 1. Add security checking at the entity field level.
 Right now security checking is done only at the entity level.

 2. Improve the ArtifactPath class design. Right now the
 class exposes too much of its implementation, and the
 ContextUtil class exploits that. Client code should not
 know that the path is stored as an array.

 3. Encapsulate the
 Push Artifact->Run Protected Process->Pop Artifact
 code into a single method.

 ---------------------------------------------------

 2010-01-13: The main navigation is controlled by the new
 security design. I created a new class - ContextUtil.java -
 to hold utility methods. Those methods can be moved to
 other components when the branch is merged into the trunk.

 An interesting side-effect of the new security design is
 its ability to expose security holes in the trunk. Log in
 as admin, go to Party Manager and click on the Find button.
 The exception that is thrown exposes a flaw in the
 findparty.ftl file.

 I added security audit capability. This was not in the
 design document, but it was simple to implement and might be
 useful. An artifact can be flagged as audited. Any denied
 attempts to use the artifact will be logged.

 ---------------------------------------------------

 2010-01-11: The ExecutionContext implementation is fairly complete.

 The security-aware artifacts implementation is mostly complete
 (the AuthorizationManager CRUD methods are not written and the
 EntityListIterator is not security-aware), but its use
 in the branch is still proof-of-concept. In other words, the
 design is implemented and working, but very little of the project uses it.

 Example: The screen renderer doesn't catch the security exceptions,
 so when a user is denied access to an artifact they get the JSP error page.

 ---------------------------------------------------

 2010-01-05: Artifact paths now support substitution ("?")
 and wildcard ("*") path elements.
 This solves an issue that was discussed during the design - how
 to grant access to a particular artifact regardless of the
 execution path. You can see examples of their use in
 framework/security/data/SecurityData.xml and
 framework/example/data/ExampleSecurityData.xml.

 The Example component has been converted to the new
 security design.

 The Execution Context seems to fulfill all needs so far, and it
 works pretty well, so its API could be considered stable at
 this time.

 ---------------------------------------------------

 2009-12-31: I put this text file in the branch as a means
 of keeping anyone who is interested updated on the progress
 of the branch.

 This branch is an implementation of the Security-Aware Artifacts
 design document -

 http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign

 and it is a work in progress.

 The ExecutionContext interface is
 scattered across several components due to the cross-dependency
 or circular-dependency issue. Cross-dependency is when Class
 A references Class B, and Class B references Class A, and both
 classes are in separate components. There is no way to get them
 to compile. The problem is compounded in ExecutionContext because
 it references 3 or 4 components.

 The workaround I came up with was to have the lowest level methods
 declared in the base component, then have each component extend
 the interface and add their methods. It's not pretty, but it works.

 This is where you can find the interfaces:

 org.ofbiz.base.context.ExecutionContext
   org.ofbiz.entity.ExecutionContext
     org.ofbiz.service.ExecutionContext

 When the cross-dependency issues are solved, all of the extended
 interfaces will be consolidated into one.

 The interface implementations can be found in the context component.

 The ultimate goal of ExecutionContext is to have all client code
 get the contained objects from ExecutionContext only - instead of
 getting them from the various classes now in use. This initial
 implementation focuses more on the ExecutionContext's role as
 a means of tracking the execution path - which is needed for the
 security-aware artifacts.

 The AuthorizationManager and AccessController interfaces are based
 on the java.security.* classes, and they are intended to be
 implementation-agnostic. OFBiz will have an implementation based
 on the entity engine, but the goal is to be able to swap out that
 implementation with another.

 If you want to see the ExecutionContext and AccessController in
 action, change the settings in api.properties. You will see info
 messages in the console log.

 I added a security-aware Freemarker transform. Template
 sections can be controlled with:

 <@ofbizSecurity permission="view" artifactId="thisTemplate">Some text</@ofbizSecurity>

 If the user has permission to view the artifact, then "Some text"
 will be rendered.

 The Authorization Manager is mostly working. Filtering
 EntityListIterator values is not implemented due to architectural
 problems.
	ExecutionContext and Security-Aware Artifacts Notes
	---------------------------------------------------

	2010-01-20: Security-aware artifact TODOs:

	1. Add security checking at the entity field level.
	Right now security checking is done only at the entity level.

	2. Improve the ArtifactPath class design. Right now the
	class exposes too much of its implementation, and the
	ContextUtil class exploits that. Client code should not
	know that the path is stored as an array.

	3. Encapsulate the
	Push Artifact->Run Protected Process->Pop Artifact
	code into a single method.

	---------------------------------------------------

	2010-01-13: The main navigation is controlled by the new
	security design. I created a new class - ContextUtil.java -
	to hold utility methods. Those methods can be moved to
	other components when the branch is merged into the trunk.

	An interesting side-effect of the new security design is
	its ability to expose security holes in the trunk. Log in
	as admin, go to Party Manager and click on the Find button.
	The exception that is thrown exposes a flaw in the
	findparty.ftl file.

	I added security audit capability. This was not in the
	design document, but it was simple to implement and might be
	useful. An artifact can be flagged as audited. Any denied
	attempts to use the artifact will be logged.

	---------------------------------------------------

	2010-01-11: The ExecutionContext implementation is fairly complete.

	The security-aware artifacts implementation is mostly complete
	(the AuthorizationManager CRUD methods are not written and the
	EntityListIterator is not security-aware), but its use
	in the branch is still proof-of-concept. In other words, the
	design is implemented and working, but very little of the project uses it.

	Example: The screen renderer doesn't catch the security exceptions,
	so when a user is denied access to an artifact they get the JSP error page.

	---------------------------------------------------

	2010-01-05: Artifact paths now support substitution ("?")
	and wildcard ("*") path elements.
	This solves an issue that was discussed during the design - how
	to grant access to a particular artifact regardless of the
	execution path. You can see examples of their use in
	framework/security/data/SecurityData.xml and
	framework/example/data/ExampleSecurityData.xml.

	The Example component has been converted to the new
	security design.

	The Execution Context seems to fulfill all needs so far, and it
	works pretty well, so its API could be considered stable at
	this time.

	---------------------------------------------------

	2009-12-31: I put this text file in the branch as a means
	of keeping anyone who is interested updated on the progress
	of the branch.

	This branch is an implementation of the Security-Aware Artifacts
	design document -

	http://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign

	and it is a work in progress.

	The ExecutionContext interface is
	scattered across several components due to the cross-dependency
	or circular-dependency issue. Cross-dependency is when Class
	A references Class B, and Class B references Class A, and both
	classes are in separate components. There is no way to get them
	to compile. The problem is compounded in ExecutionContext because
	it references 3 or 4 components.

	The workaround I came up with was to have the lowest level methods
	declared in the base component, then have each component extend
	the interface and add their methods. It's not pretty, but it works.

	This is where you can find the interfaces:

	org.ofbiz.base.context.ExecutionContext
	org.ofbiz.entity.ExecutionContext
	org.ofbiz.service.ExecutionContext

	When the cross-dependency issues are solved, all of the extended
	interfaces will be consolidated into one.

	The interface implementations can be found in the context component.

	The ultimate goal of ExecutionContext is to have all client code
	get the contained objects from ExecutionContext only - instead of
	getting them from the various classes now in use. This initial
	implementation focuses more on the ExecutionContext's role as
	a means of tracking the execution path - which is needed for the
	security-aware artifacts.

	The AuthorizationManager and AccessController interfaces are based
	on the java.security.* classes, and they are intended to be
	implementation-agnostic. OFBiz will have an implementation based
	on the entity engine, but the goal is to be able to swap out that
	implementation with another.

	If you want to see the ExecutionContext and AccessController in
	action, change the settings in api.properties. You will see info
	messages in the console log.

	I added a security-aware Freemarker transform. Template
	sections can be controlled with:

	<@ofbizSecurity permission="view" artifactId="thisTemplate">Some text</@ofbizSecurity>

	If the user has permission to view the artifact, then "Some text"
	will be rendered.

	The Authorization Manager is mostly working. Filtering
	EntityListIterator values is not implemented due to architectural
	problems.