A checkpoint is a specified point in a session when Oracle Adaptive Access Manager collects and evaluates security data using the rules engine.
New checkpoints can be added and existing checkpoint properties can be modified using the Properties Editor.
This chapter provides information on how to create and configure a new checkpoint and how to modify an existing checkpoint. It includes the following sections:
To create a checkpoint, use the Properties Editor.
The following checkpoint enumeration is shown for your reference.
profile.type.enum.nameofcheckpoint=Checkpoint_Value profile.type.enum.nameofcheckpoint.name=Checkpoint_Name profile.type.enum.nameofcheckpoint.description=Checkpoint_Description profile.type.enum.nameofcheckpoint.ruleTypes=user,device,location profile.type.enum.nameofcheckpoint.listTypes=vtusers profile.type.enum.nameofcheckpoint.finalactionrule=process_results.rule profile.type.enum.nameofcheckpoint.isPreAuth=true
The Checkpoint value must unique number. Make sure no other checkpoint uses the identifier. This ID is like a primary key in database terminology. For example, "1001."
The Checkpoint name must be user-presentable and meaningful. The name is used in Oracle Adaptive Access Manager.
If the checkpoint creation is successful, add the appropriate properties by clicking the Add New button under the Properties box.
The Checkpoint's required properties are:
finalactionrule=process_results.rule
The "finalactionrule" property specifies the Rule file that decides the final action. When the Rules Engine processes the policies for the checkpoint, it determines the score and a list of actions. The final action list is list of action that are deemed final when rules are run. The rule file is consulted to see what action should be given as final action. If you are not sure, set the value as in the other checkpoints.The out-of-the-box "process_results.rule" file is sufficient for most actions.
An example of the rule file is provided in Section 26.4, "Final Action."
listTypes= vtusers
Always set listTypes to "vtusers."
The policy can be linked to only usergroups.
ruleTypes= user,device,location,in_session
The "ruleTypes" property defines the list of rule types supported during the checkpoint. Depending on the context of the checkpoint, possible values are "user," "device," "location," and "in_session." Use commas to separate multiple values. You can use all rules of the comma separated types in this checkpoint.
For example if you set ruleTypes to "user,location," you can use the rules of the type "user" and "location" in the checkpoint, and the user and location information is available for this checkpoint.
Another example, for the "Cancel Order" checkpoint, if "user,device,location" are specified for ruleTypes, the "user" Rule type expects that the user information to be available during the "Cancel Order" checkpoint. If the user information is not available at the time of the "Cancel Order" checkpoint, "user" should not be included in the list.
Other properties you may add are:
isPreAuth
True indicates that this checkpoint is a pre-authentication checkpoint. OAAM Admin updates the user details with the pre-auth score and pre-auth action. The default for isPreAuth is "false." There cannot be two checkpoints with this flag set to "true." Also the same checkpoint cannot be marked as postAuth and preAuth.
isPostAuth
True indicates that this checkpoint is a post-authentication checkpoint. OAAM Admin updates the user details with the post-auth score and post-auth action. The default for isPostAuth is "false." There cannot be two checkpoints with this flag set to "true." Also the same checkpoint cannot be marked as postAuth and preAuth.
After creating the checkpoint, you must restart the server.
An example for creating the "addressChange" checkpoint is shown:
profile.type.enum.addressChange=88 profile.type.enum.addressChange.name=Address Change profile.type.enum.addressChange.description=Address Change checkpoint profile.type.enum.addressChange.ruleTypes=user,device,location profile.type.enum.addressChange.listTypes=vtusers profile.type.enum.addressChange.finalactionrule=process_results.rule profile.type.enum.addressChange.isPreAuth=true
For finalactionrule, "process_results.rule" was provided because the Final Action for a given checkpoint during rules evaluation is determined by this rule file. File process_results.rule is supplied out-of-the-box and no additional steps are required.
A new action can be defined through OAAM Admin when you define action groups and when you want to add an action, which gives a choice to create an action. You can also create an action by adding an element to rule.action.enum.
If a new action is defined and it is the final action of a checkpoint, you must perform the following steps.
Locate the rule file for that checkpoint or define one if you are creating a new checkpoint. This file ensures that the action that is supposed to be final is available in the final action list when the rules are run.
If you do not want to use the default file, the subsequent example is provided to illustrate what the file looks like. You will want to include the rule file in the OAAM Extensions Library which is in the OAAM Server's classpath.
==
<rule name="Block" no-loop="true" salience="100">
<parameter identifier="actionList">
<class>java.util.List</class>
</parameter>
.
<java:condition>actionList.contains("Block")</java:condition>
.
<java:consequence>
if (logger != null){
logger.debug("Executing Block condition");
}
.
finalAction.append("Block");
drools.clearAgenda(); <!-- This stops any other rules from being
evaluated -->
</java:consequence>
</rule>
Locate or create the finalactionrule property for that checkpoint.
For example, for checkpoint "X" it will be
profile.type.enum.X.finalactionrule=some_file_name.rule
Add the rule file to a shared library and make that library available to the OAAM Server. You can package the file in the OAAM_extensions library since it is available to server.
The previous example shows that the final action list contains the Block action. If you are defining your own checkpoint, you may also want to perform the previous steps and set your finalactionrule property to point to the file created. The preceding rule file must be in the classpath of the servers so that oaam_server and oaam_offline server can use this information. After defining rule file or creating such file, the servers will have to be restarted.