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