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.