Using OES to Secure POJOs - Fact or Fiction?

In providing access control, there are two "main" functions - policy enforcement and policy evaluation.

The Policy Enforcement Point (PEP) intercepts the request and asks the Policy Decision Point (PDP) to evaluate the request. The PDP responds - yes/no - and then the PEP either lets the call continue or blocks the request. A good example of this whole model can be found in the XACML spec.

So, when looking at the question "Can OES be used to secure POJOs?" we need to looks at both parts of the model - PEP and PDP.

On the PDP side, OES is sufficiently flexible to perform the task. The OES resource model allows for a hierarchal names. This maps nicely to Java class names:

//resource/com/foo/Customer

Using this model, you could write policies to block access to packages or classes - sorta useful. But probably not the main case. What about methods? There are really two choices here. The first is mapping the method invocation to the action.

//priv/getBalance //resource/com/foo/Customer

The second is going with a generic action and putting the action as the lead note of the resource:

//priv/invoke //resource/com/foo/Customer/getBalance

The latter makes it easier to write policies for "all actions on an object".

Now, what about access control at the instance level? I want to write a policy that says that 'Joe can get the balance of the customer if the customer is in state="MA"'

grant (//priv//invoke, //resource/com/foo/Customer/getBalance, //user/foo/Joe) if state="MA"

Makes sense, but how does OES get the state of the customer object?

OES has the ability to pass information from the PEP to the PDP. This includes Java objects. Either the PEP could use Java reflection to pass the attributes or the PEP could pass the instance (assuming its serializable) and OES could use attribute retrievers to get the values from the instance.

In a previous post, I discussed customers' desire for PEPs (Policy Enforcement Points). So, how would you go wire this in?

It depends on what container, if any, you are using. With no container, you need to look at AOP to insert these calls pre-method. In spring, you could do this with ACEGI + OES. If you are willing to make some small code changes, maybe look at securing the classes with custom java Permissions.

In my experience, I haven't seen a need for securing all POJOs. If this is the case, then use Java Security and custom permissions. What I have seen is the need to secure a small number of very sensitive classes. In this case, look at what the container provides, or possibly modifying the class to explicitly call to OES.