Customers have a large variety of requirements suiting their particular business needs when it comes to managing corporate content. UCM provides a great deal of flexibility for companies to store, categorize and manage their documents and content in general. OES has also a lot of flexibility when providing sophisticated security schemes to control access to that content. However, if we are not careful making the right decisions, the actual solution may not live up to the task at hand and may be more disappointing than anything else.
Recently, I had the opportunity to reassemble the OES-UCM integration for a POC in EMEA. During the engagement, I realized that most customers, not only in that region but pretty much in general, use Accounts in UCM. One specific requirement of this POC was to be able to simplify how the relationships between documents are accounts are maintained without having to touch every single document. So the intent here is to describe a potential solution to this problem which could be recommended to customers and doesn’t necessarily represent what real customers currently have in place.
First of all, let’s do a quick overview of the integration’s architecture to have an initial picture of what we have at our disposal to tackle this problem.
For starters, on the UCM side a custom component implementing UCM’s filter interfaces is required to tie OES into UCM’s hooks for custom integrations. Part of this component would be an OES API Wrapper object that will provide the UCM components with a mechanism to call out to OES when the events invoking the custom component are triggered. The following diagram shows the basic architecture of the integration:
Fig. 1 – Basic Integration Architecture UCM-OES.
As described in previous posts the configuration of the java-ssm instance part of the integration as shown above is embedded into UCM via the intradoc.cfg configuration file. So the flow is basically like follows:
1. User logs in to UCM and it is authenticated by UCM providers.
The attribute retrievers are specially useful for the purposes of dynamic business logic evaluation impacting authorization decisions.
Evaluation Functions
For our purposes, evaluation functions are a key piece of the puzzle, and you’ll know why soon.
Requirements and Solutions
UCM has all the facilities to configure these relationships, so what value is added by OES? Well, OES can enrich the semantics of what it actually means to be part of the account and with what privileges. UCM has just direct assignment of users into HRDocAdmin account and with specific permissions. OES on the other hand can actually say: “The user is a member of the HRDocAdmin account if he belongs to the HR Director’s department and has the title ‘HR Auditor’ but only until March 2011”. The way OES policies are specified allow for a more comprehensive analysis of the user’s attributes along with present circumstances external to the user’s profile to determine if a user is part of the account and with what privileges. In other words, OES makes it possible to express the relationship between users and account in a more dynamic fashion.
Going back to the requirements, I am going to present a possible solution to the requirements of using a hierarchy of accounts to protect content and use OES as the engine to determine user access to accounts and therefore to their respective protected resources.
• North East Organization
• North Central Organization
• South West Organization
• South East Organization
• South Central Organization
A set of states belongs to each Organization. Each state has its own set of content items in UCM. Only people from a given state with Author or ContentAdmin roles can modify the documents that belong to that state. Other Authors/ContentAdmins in other States within the same Organization still have read access to those documents. So in other words everyone within an organization has access to the account that belongs to that organization, but the permissions over the content vary based on the state that generated the document. Needless to say, People in other organizations don’t have access to documents that don’t belong to their organization because they will have no access over the corresponding accounts. If we wanted to take this even further, we could easily design a scheme of exceptions for inter-organization access to content generated by different organizations. As a matter of fact, if the content is labeled public in an attribute called xDocExceptionStatus part of the metadata associated to the content item; then everyone has access to that document regardless of the account privileges.
package oes;
import java.util.Map;
import javax.security.auth.Subject;
import weblogic.security.spi.Resource;
import weblogic.security.service.ContextHandler;
import com.bea.security.providers.authorization.asi.ARME.evaluator.RequestHandle;
public class UCMOESEvaluationFunction {
public UCMOESEvaluationFunction() {
super();
}
public boolean assertAttributes (RequestHandle requestHandle, Object[] args, Subject subject, Map roles, Resource resource, ContextHandler contextHandler) {
AttributeElement xDocExceptionStatus = requestHandle.getAttribute("xDocExceptionStatus",true);
AttributeElement xDocState = requestHandle.getAttribute("xDocState",true);
AttributeElement xDocOrg = requestHandle.getAttribute("xDocOrg",true);
String strXDocExceptionStatus = xDocExceptionStatus.getValueAs(String.class);
String strXDocState = xDocState.getValueAs(String.class);
String strXDocOrg = xDocOrg.getValueAs(String.class);
if (strXDocExceptionStatus.equalsIgnoreCase("public")) {
return true;
}
else {
try {
if (strXDocExceptionStatus.equalsIgnoreCase("restricted")) {
return args[0].toString().equalsIgnoreCase(strXDocOrg);
}
else {
return (args[0].toString().equalsIgnoreCase(strXDocState) &&
args[0].toString().equalsIgnoreCase(strXDocOrg));
}
}
catch (Exception e ) {
e.printStackTrace();
return false;
}
return false;
}
void init(Map config) {
}
void shutdown() {
}
}
All this function does is to extract the Attributes from the document’s metadata passed as properties from the client. It does that using the requestHandle parameter passed to the function method. Then compares the values with the ones passed as arguments to the function from the OES policy using this function. Within the policy OES passes the values of the dynamic attributes for st (State) and o (Organization) using the following constraint expression:
sys_defined(st) AND sys_defined(o) AND assertAttributes(st, o)
As shown by the expression above, only users that exist in LDAP having these attributes populated will be evaluated for access. The first two calls to sys_defined function prevent non-LDAP stored users from making it through to our evaluation function, so these users get rejected immediately. Part of the configuration would be having two dynamic attributes tied to the same LDAP attribute retriever.
By doing this we are adding a sophisticated access policy that would fit the business requirements for the accounts without the limitations from UCM policies based on simple group membership.
The deployment of the function above is described In Oracle Entitlements Server documentation and is out of scope for this document, so please refer to it if you want to try this approach.
Summary
OES can extend the security model of UCM so the semantics of access policies can be enriched to support more sophisticated authorization schemes.
The combination of Attribute Retrievers and Evaluation Functions is a very powerful mechanism to implement sophisticated access policies with very rich semantics and also a very dynamic nature if the users' data change overtime affecting their access to content stored in UCM.
This is just a sample implementation of potential requirements. It is not intended to serve as the basis of a real implementation meant to be released in production.
Posts
