Friday, September 11, 2009

Oracle Entitlements Server (OES) Using Oracle Coherence for Access to Distributed Attribute Data

The value of this solution is that someone can use the data in the grid to create specific entitlement policies. The data used for the entitlement could be updated at anytime using a Coherence application to dynamically change the result of a policy at run-time based on business needs or conditions.

This use-case can be done for accessing distributed attribute data in a cache grid. Many end-users already use Oracle Coherence and re-using the information from a Coherence Grid with OES would strengthen a distributed SOA environment. These name/value pairs from a Coherence Grid can be used as attributes within Oracle Entitlements Server (OES).


How does this currently work?

OES can use the Oracle Coherence product to access an Oracle Coherence Data Grid. At startup of the OES Security Module, the Coherence product will startup and connect to a configured Coherence cluster containing distributed data. Once Coherence connects, it automatically gets a copy of all the data already within that grid. The data can be retrieved with a custom OES Attribute Retriever for use in Authorization Policy decisions for an application. See the diagram below which shows how this works "Out-of-the-Box" today:



Current Solution for OES/Coherence Attribute Retrievers

This use-case can currently be solved using OES and Coherence. In the description below a WebLogic Portal application was used with OES, a custom attribute retriever and Coherence in a sample domain/test environment.


NOTE:
  • Any application can be used for testing and a "WebLogic Portal" application is not necessary. It is used as an example here of what it would look like.


  1. Setup you WLS Domain:

  2. Add the coherence jar files to the setDomainEnv.bat/sh script and make sure you specify a host for the Coherence Cluster being used as mentioned above:

    set COHERENCE_OPTIONS=-Dtangosol.coherence.localhost=169.254.25.129
    set JAVA_OPTIONS=%JAVA_OPTIONS% %COHERENCE_OPTIONS%

    @REM SET THE CLASSPATH
    set COHERENCE_DIR=\coherence-3.3.1\lib
    set COHERENCE_LIBS=%COHERENCE_DIR%\tangosol.jar;%COHERENCE_DIR%\coherence.jar;%COHERENCE_DIR%\coherence-web.jar
    set CLASSPATH=%PRE_CLASSPATH%;%WEBLOGIC_CLASSPATH%;%POST_CLASSPATH%;%WLP_POST_CLASSPATH%;%COHERENCE_LIBS%

    NOTE: Coherence is using the default cache-config.xml file which is bundled within the coherence jar files. The implication of this is that Coherence is not tune for performance and if one wants to override this, then a -Dtangosol.coherence.cacheconfig= flag would need to be applied to the java start line for WebLogic Server pointing to the coherence configuration file of choice.


  3. Run a client to load the data into the coherence grid. In this case the only cluster member of the Coherence Grid is the Coherence Server started within the container. The idea is that there is *already* an existing Coherence Grid with Distributed Data which one will connect to.


  4. Start the WLS Domain which has its security enforced by OES with the startWebLogic.cmd/sh file. Within OES an Attribute Retriever is used which gets the requested attribute from the Coherence Grid. See the sample Attribute Retriever Code below.


  5. Make sure the Attribute Retriever and attribute being used is configured within the Authorization Provider of the WLS container.


  6. Test your sample application to see if your policy which has the attribute being retrieved will retrieve it from the Coherence Grid. In this example, a Portal application was used and I modified the following resource within the OES Administration Console to check the value of the attribute we are retrieving:



  7. Resources: BEAPortalSample/wlp/portalAndALES_WAR/com_bea_p13n/Page/QL_portal_Education_and_Support
    Constraint: checkIncominAttrRet(accesspage, execPage) and coh_AccessPage = "OK"
    Subjects: USER:beaID:weblogic


  8. Access the Portal application URL and login.


  9. If the Coherence Grid is running, then the value of "OK" should be returned in the Attribute Retriever


  10. As a test, change the value in the Grid for the "coh_AccessPage" attribute to something other than "OK".


  11. Logout of the Portal application and log back in. This time you will see a different result and the user not authorized to see the page. If you are having problems with the authorization, please review the previous blog on Troubleshooting authorization decisions.





OES Custom Attribute Retriever Code


The Coherence added code is in bold:

package com.bea.ales.sample2;

import com.bea.security.providers.authorization.asi.AttributeRetriever;
import weblogic.security.spi.Resource;
import weblogic.security.service.ContextHandler;

import javax.security.auth.Subject;
import java.util.*;

// Modify the build path for this application to include
// the tangosol.jar and coherence.jar files within one's environment.
import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;

/**
* Implementation for performing attribute retrieval.
* This plugin can get to remote repositories to figure out the value
* of a certain attribute at runtime. Multiple retrievers may be
* registered for the same attribute name, they will be called in
* order until one returns a non-null result.
*/
public class CohAttributeRetriever implements AttributeRetriever {

private static final String cohaccessPage = "coh_AccessPage";
private String[] attributes = {cohaccessPage };
private NamedCache myCache = null;


// “Prime” the Coherence information within the constructor
// of the AttributeRetriever
public CohAttributeRetriever() {

CacheFactory.ensureCluster();
myCache = CacheFactory.getCache("mycache");
}
/**
* Returns the names of attributes handled by this class.
* indicates that the retriever will be considered capable of
* handling any attribute name.
*
* @return the names associated with this object
*/
public String[] getHandledAttributeNames() {
return attributes;
}

/**
* Retrieve the value of the named attribute.
* Additional authorization request data
* is made available to allow for more complex attribute retrieval.
*
* @param name the name of the needed attribute
* @param subject the subject associated with the request
* @param roles the role membership of the subject
* @param resource the resource associated with the request
* @param contextHandle the context associated with the request
* @return the attributes value, or null if not found
*/
public Object getAttributeValue(String name,
Subject subject,
Map roles,
Resource resource,
ContextHandler contextHandle) {

// Set default value
String attrValue = "no";

if (name.equals(cohaccessPage)) {

try {

// The only call to the Coherence Named Cache to get
// whatever attribute is needed from the Coherence Grid

attrValue = (String)myCache.get(cohaccessPage);

System.out.println("--> COH Value is \"" + attrValue + "\"");
} catch (Exception e) {
System.out.println("E:"+e.getLocalizedMessage()+" "+ e);
}
finally {}
return attrValue;
}

// default value returned...
return attrValue;
}

}//end of AttributeRetriever

Friday, September 4, 2009

Step by Step Details on Debugging an Oracle Entitlements Server (OES) Security Module Instance

The following details how-to troubleshoot authorization failures in an Oracle Entitlements Server Security Module Instance. The OES product is available for download from the following link.


What is OES? From the OES documentation: "Oracle Entitlements Server provides fine-grained entitlement management solution that secures critical applications with performance and reliability. By combining centralized policy management with distributed policy decision-making and enforcement, it allows you to rapidly adapt to changing business requirements. Typical uses include fine-grained entitlements for application functionality, dynamic data redaction and privacy at the source, and controlling access to web service endpoints."


Troubleshooting:

If the issue at hand is troubleshooting in development “why” a particular policy was either a GRANT or DENY then the best thing to do would be to enable debugging with the SSM instance’s log4j.properties file which is located in the “config” directory of the SSM instance. Once that is done, restart the SSM instance, run the application in question to exercise the policy, and then look into the SSM “instance” log directory for the system_console.log file. Open this file up in a text editor, scroll to the bottom and look for the policy decision in question to understand why a policy evaluated the way it did.


Step by Step Details on Debugging an SSM Instance:

Enable debugging on the RMI-SSM to see verbose debug logging as the application is run. This is a good place to look in order to determine why something is or is not authorized. To enable debugging in this example, goto the OES_HOME\ales32-ssm\rmi-ssm\instance\\config directory. In the following example there is an RMI-SSM instance called "CoherenceSSM" which one will see referenced.

  1. Edit the log4j.properties file and uncomment these lines: log4j.logger.com.bea.security.providers.authorization = DEBUG log4j.logger.com.wles.util.DebugStore=DEBUG
  2. Clear out the log files in BEA_HOME\ales32-ssm\rmi-ssm\instance\CoherenceSSM\log
  3. Re-start the SSM instance.
  4. View the “system_console.log” file under BEA_HOME\ales32-ssm\rmi-ssm\instance\CoherenceSSM\log
  5. This will show an example of an incorrect authorization because the user “dave” is not part of the Coherence_Group for this resource:

  6. 2009-02-03 21:18:49,969 [RMI TCP Connection(2)-141.144.104.221] DEBUG com.wles.util.DebugStore - queryAccess: DebugStore:
    ========== Policy Evaluation Info ==========
    RequestResource is: //app/policy/CoherenceSSM/__ASTR_
    UserInfo:
    Name: //user/asi/dave/
    Groups: //sgrp/asi/allusers/
    Resource Present: true
    Roles Granted: NONE
    Role Mapping Policies: NONE
    ATZ Policies: NONE
    ========== Policy Evaluation Info ==========
    2009-02-03 21:18:49,969 [RMI TCP Connection(2)-141.144.104.221] DEBUG com.bea.security.providers.authorization.asi.ARME.engine.ARME - unlock policy lock for read
    2009-02-03 21:18:49,969 [RMI TCP Connection(2)-141.144.104.221] DEBUG com.bea.security.providers.authorization.asi.AuthorizationProviderImpl - result is UNKNOWN
    2009-02-03 21:18:49,969 [RMI TCP Connection(2)-141.144.104.221] INFO com.bea.security.providers.authorization.asi.AccessResultLogger - Subject Subject:
    Principal: asi
    Principal: dave
    privilege join resource //app/policy/CoherenceSSM/__ASTR_ result ABSTAIN


  7. This will show an example of an correct authorization because the user “steve” IS part of the Coherence_Group for this resource:
    2009-02-03 21:21:57,969 [RMI TCP Connection(4)-141.144.104.221] DEBUG com.wles.util.DebugStore - queryAccess: DebugStore:


  8. ========== Policy Evaluation Info ==========
    RequestResource is: //app/policy/CoherenceSSM/testCache
    UserInfo:
    Name: //user/asi/steve/
    Groups: //sgrp/asi/Coherence_Group/ //sgrp/asi/allusers/
    Resource Present: true
    Roles Granted: NONE
    Role Mapping Policies: NONE
    ATZ Policies:
    1. Result: true; Policy Type: grant
    Privilege: any
    Resource: //app/policy/CoherenceSSM/testCache
    Subject: //sgrp/asi/Coherence_Group/
    Constraints: NONE
    Delegator: null

    ========== Policy Evaluation Info ==========
    2009-02-03 21:21:57,969 [RMI TCP Connection(4)-141.144.104.221] DEBUG com.bea.security.providers.authorization.asi.ARME.engine.ARME - unlock policy lock for read
    2009-02-03 21:21:57,969 [RMI TCP Connection(4)-141.144.104.221] DEBUG com.bea.security.providers.authorization.asi.AuthorizationProviderImpl - result is GRANT
    2009-02-03 21:21:57,969 [RMI TCP Connection(4)-141.144.104.221] DEBUG com.bea.security.providers.authorization.asi.AccessResultLogger - Subject Subject:
    Principal: asi
    Principal: steve
    Principal: Coherence_Group
    privilege join resource //app/policy/CoherenceSSM/testCache result PERMIT