15 Creating Checkpoints

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.

15.1 Creating a New Checkpoint

To create a new checkpoint, use the Properties Editor.

The enumeration for a checkpoint is shown below for your reference.

profile.type.enum.<nameofcheckpoint>=<Checkpoint Value>
profile.type.enum.<nameofcheckpoint>.name=<Checkpoint Name>
profile.type.enum.<nameofcheckpoint>.description=<Checkpoint Description>

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 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.

  • 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. All Rules of the comma separated types can be used in this checkpoint.

    For example if ruleTypes is set to "user,location," the Rules of the type "user" and "location" can be used in this 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." Note that 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." Note that 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 need to restart the server.

15.2 Creating a Checkpoint Example

Below is an example for creating the "addressChange" checkpoint.

profile.type.enum.addressChange.name=Address Change
profile.type.enum.addressChange.description=Address Change checkpoint

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.