Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager
11g Release 1 (11.1.1)

Part Number E15480-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

12 Configurable Actions

Oracle Adaptive Access Manager provides Configurable Actions, a feature which allows users to create new supplementary actions that are triggered based on the result action and/or based on the risk scoring after a checkpoint execution. This section describes how to integrate a Configurable Action with the Oracle Adaptive Access Manager software.

12.1 Integration

To add a new Configurable Action, perform the following tasks:

  1. Develop the Configurable Action by implementing the com.bharosa.vcrypt.tracker.dynamicactions.intf.DynamicAction java interface.

    Note:

    In this step, implementing means writing java code based on the contract specified by the Java interface com.bharosa.vcrypt.tracker.dynamicactions.intf.DynamicAction.

    While implementing the com.bharosa.vcrypt.tracker.dynamicactions.intf.DynamicAction java interface, the following two methods have to be coded:

    • getParameters() - In this method, the code has to be written that returns the parameters used by the Configurable Action. Make sure that the size of the parameters array returned is the same as the number of parameters. Look at the sample configurable actions java code in Oracle Adaptive Access Manager Sample application.

    • execute() - In this method, code has to be written that performs the logic required by the Configurable Action. Configurable Action parameter values are passed in actionParamValueMap where the parameter name is the key and the RuntimActionParamValue object is the value. Use the appropriate getXXXValue() method to get the parameter value.

  2. Compile your custom java classes that extend or implement Oracle Adaptive Access Manager classes by adding the jars from $ORACLE_IDM_HOME\oaam\cli\lib folder to the build classpath.

  3. Test the implementation of the Configurable Action thoroughly.

    Since Configurable Actions are standalone java classes, they can be tested with Unit Testing Methodology using JUnit framework.

    For sample JUnit code for testing configurable actions, refer to the "Sample JUnit Code" section.

  4. Compile the java class and create a jar file of the compiled class files.

  5. Extend/customize Oracle Adaptive Access Manager to add the custom jar. Refer to Section 4.1.4, "Customizing/Extending/Overriding Oracle Adaptive Access Manager Properties" for steps for adding the custom jar to Oracle Adaptive Access Manager.

  6. Restart OAAM Server and the OAAM Admin Server.

  7. Log in to OAAM Admin and create an action definition entry for the newly deployed Configurable Action.

  8. Make sure all the parameters required for the Configurable Action are displayed in the user interface.

  9. Use the newly available Configurable Action by adding it to the required checkpoints. For more information on configuring Configurable Actions, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

12.2 Executing Configurable Actions in a Particular Order and Data Sharing

Configurable Actions can be used to implement chaining in such a way that

Note:

Sharing data across Configurable Actions involves writing java code and requires more effort than just a configuration task.

To be able to execute Configurable Actions in a particular order and share data:

  1. Configure Configurable Actions as synchronous actions with the required order of execution in ascending order.

    Note:

    A Configurable Action is executed only if the trigger criteria is met; therefore, make sure the trigger criteria is correct.

  2. To share data, insert the data into the actionContextMap parameter of the Configurable Action's execute() method. Since the actionContextMap is a Map, it requires a key and value pair that represents the data to be shared.

    Note:

    it is the implementer's responsibility to ensure that

    • the duplicate keys are not used while inserting data

    • the same key is used when trying to access this shared data from another Configurable Action.

  3. Ensure that the code can handle the case where the key is not present in the actionContextMap. This step must be performed to avoid errors or NullPointerException when the other action do not insert the value into the actionContextMap.

12.3 How to Test Configurable Actions Triggering

To test if configurable actions triggering:

  1. Make sure there is a way to identify if the code in the Configurable Action is executed. This could be as simple as an entry in log file or an entry in database.

  2. Enable debug level logging for oracle.oaam logger in OAAM Server.

  3. Create an action template for the given Configurable Action.

  4. Add the action to a Pre-Authentication checkpoint with trigger criteria as score between 0 and 1000.

  5. Try logging in to OAAM Server as a user.

  6. Check OAAM Server logs for the entry Enter: executeAction(): Executing Action Instance.

  7. If there is no error then you will see a related log statement like Exit: executeAction(): Action Instance.

  8. If there is an error, you will see a log statement like Error: executeAction().

  9. Apart from these, check for a log entry or a database entry that is created by the Configurable Action itself

12.4 Sample JUnit Code

The following is an sample JUnit code for testing dynamic action:

public class TestDynamicActionsExecution extends TestCase {
        static Logger logger = Logger.getLogger(TestDynamicActionsExecution.class);
        private DynamicAction caseCreationAction = null;
 
 
        public void setUp()throws Exception {
                caseCreationAction = new CaseCreationAction();
    }
 
        public void testDynamicAction() {
 
                //RequestId
                String requestId = "testRequest";
 
                //Request Time
                Date requestTime = new Date();
 
                //Map that contains values passed to the rule/model execution
                Map ruleContextMap = new HashMap();
 
                //Result from rule execution
                VCryptRulesResultImpl rulesResult = new VCryptRulesResultImpl();
                rulesResult.setResult("Allow");
                rulesResult.setRuntimeType(new Integer(1));
 
                //Configurable action's parameter values
                Map actionParamValueMap = new HashMap();
                RuntimeActionParamValue caseTypeParamValue = new RuntimeActionParamValue();
                caseTypeParamValue.setIntValue(CaseConstants.CASE_AGENT_TYPE);
 
                RuntimeActionParamValue caseSeverityParamValue = new RuntimeActionParamValue();
                caseSeverityParamValue.setIntValue(1);
 
                RuntimeActionParamValue caseDescriptionParamValue = new RuntimeActionParamValue();
                caseDescriptionParamValue.setStringValue("Testing CaseCreation Action");
 
                //ActionContext Map for passing data to/from the dynamic action execution
                Map actionContextMap = new HashMap();
 
                //Execute the action
                try {
                        caseCreationAction.execute(requestId, requestTime, ruleContextMap, rulesResult, actionParamValueMap, actionContextMap);
                }catch(Exception e) {
                        Assert.fail("Exception occurred while executing dynamic action");
                        logger.error("Exception occcurred while executing dynamic action", e);
                }
 
                //Write appropriate asserts to check if the configurable action has executed properly
        }
 
    public void tearDown() throws Exception {
 
    }
}