| Oracle® Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager Release 11g (11.1.1) Part Number E14568-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager Release 11g (11.1.1) Part Number E14568-02 |
|
|
View PDF |
This appendix provides information about the conditions available standard on Oracle Adaptive Access Manager.
This chapter focuses on device, autolearning, location, transaction, in-session, system, and user conditions.
These section provides information on the following device conditions:
| Condition | DEVICE: Browser header substring |
|---|---|
| Description | Checks whether the supplied string exists as a substring in the browser's header information. The string comparison is performed by ignoring the case (uppercase or lowercase) of the strings. |
| Pre-Requisites | |
| Assumptions | The rule is configured through a policy. |
| Available since version | Pre-10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| subString | Substring to be checked with the string present in the browser. | Yes |
Possible User Scenarios
This condition could potentially be used to determine if the user is logging in from a particular version of a browser that is prone to security problems.
| Condition | DEVICE: Device firsttime for user |
|---|---|
| Description | Checks to see if the user is using this device for the first time. Note that "device" is the combination of the physical device and the browser in most of the test scenarios. Check the page of the recent login to determine the Device ID associated with the login sessions to verify the rule. The user's current (session) device is also counted if is found to be used for the first time. |
| Pre-Requisites | The rule should be configured through a policy. |
| Assumptions | |
| Available since version | Pre-10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| is | Boolean that checks if the condition should return true or false if the user is using this device for the first time | true (default) or false | Cannot be Null. |
Possible User Scenarios
This condition could potentially be used to determine if the user is logging in from a different device or different devices and to challenge him when it is the case.
| Condition | DEVICE: In Group |
|---|---|
| Description | Checks to see if the device is in the specified list. |
| Pre-Requisites | A list defined already which has devices (IDs) as members.
You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| isInList | This is a boolean parameter that defines the default return value if the device is in the list. | True / [False] | Yes. |
| listId | This is the list of IDs of a list of devices. OAAM Admin will display a menu with the possible lists of device lists. Use the Group editor in OAAM Admin to edit the device list. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the device of the current activity belongs to a particular list of devices.
For example,
You may want to block users logging in from the device that is considered "compromised."
You may not want users to perform certain activities if they are logging in from a device that is a kiosk.
| Condition | DEVICE: Excessive Use |
|---|---|
| Description | Checks to see if this device is used excessively. Basically, checks to see if a device was not active for several days and suddenly a large number of users are logging in from the same device in a short period (in a few hours). This condition can be potentially used to track the compromised device of automated programs that obtained access to the code and then tries to log in several users. |
| Pre-Requisites | You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| userCount | Number of users logging in from a single device in a short period. | positive integers | No |
| withInHours | This parameter defines the short period in which OAAM must find excessive use. | positive integer | No |
| notInDays | This parameter describes the number of days the device was not in use. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device used in the current activity is compromised. For example, you might have certain devices that are deemed as compromised and you may want to block users logging in from them. For example, an individual could be "hacking" into a bank computer and then trying to perform various activities. Typically, activity logging should be set up for that computer for several days.
| Condition | DEVICE: Is registered |
|---|---|
| Description | Condition checks to see if the device where that the user is logging in is registered for the user. |
| Pre-Requisites | You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| is | Boolean parameter to decide if the default return value should be true or false if the device is registered. | [True] / False | Yes |
Possible User Scenarios
This condition can be used to identify if the user is logging in from a device that he has not registered before. This can basically prevent a fraud where the user's login information is stolen and the thief tries to log in using the user's login information from another otherwise safe location.
| Condition | DEVICE: User count |
|---|---|
| Description | Check to see if this device is used by several unique users in the last few seconds. This can potentially be fraud since if this condition is true then it will be potentially a compromised device or compromised login information for a number of users. |
| Pre-Requisites | You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| numberOfUsers | Number of users logging in from the same device in a short period. | positive integers | No |
| withinSeconds | This parameter defines the short period in which the number of users try to log in to the system using that device. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device used in the current activity is compromised. It could be possible that a fraudster had stolen the login information for several users and tried to ruin their accounts. The result is that many users are logging in from the same device in intervals that are a few seconds each.
| Condition | DEVICE: Timed not status |
|---|---|
| Description | This condition counts the attempts by users from the same device (the device used in the attempt) in the last few seconds where the authentication status is not the one given in the condition. If this count exceeds the count configured in the condition, then this condition evaluates to true. |
| Pre-Requisites | You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| status | Count the attempts a status that is not equal to this specified status. | auth.status.enum (auth.status.enum.success is the default) | No |
| withinSeconds | This parameter defines the short period in which the number of login attempts that use that device are counted. | positive integer | No |
| attempts | Maximum number of attempts to watch for. If the attempt count in Oracle Adaptive Access Manager exceeds this number, then the condition will evaluate to true. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device used in the current activity is compromised. A possible fraud scenario can be detected where:
An individual (or a automated program) uses the same device to make login attempts and the attempts are either failing or passing based on the data that was stolen.
A program is used to break the password in an automated fashion.
In these cases, there are repeated failed login attempts from the same device in a short amount of time.
| Condition | DEVICE: Timed not status |
|---|---|
| Description | This condition counts the attempts by users from the same device (the device used in the attempt) in the last few seconds with an authentication status that is not the one that is specified in the condition. If this count exceeds the count configured in the condition, then this condition evaluates to true. |
| Pre-Requisites | You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| status | Count the attempts with the status that is not equal to this status. | auth.status.enum (auth.status.enum.success is the default) | No |
| withinSeconds | This parameter defines the short period in which login attempts using that device are counted. | positive integer | No |
| attempts | Maximum number of attempts to watch for. If the attempt count exceeds this number then the condition will evaluate to true. | positive integer | No |
Possible User Scenarios
This condition can be potentially used to determine if the device used in the current activity is compromised.
Possible fraud scenarios that can be detected are:
An individual (or an automated program) is using same device to make login attempts and the attempts are either failing or passing based on the data that was stolen
A program is trying to break the password for user in automated fashion
In these cases, repeated failed login attempts are made from the same device in a short period.
| Condition | DEVICE: Velocity from last login |
|---|---|
| Description | Condition evaluates if the user's velocity in miles per hour is more than the specified value. The location database is used to determine the location of the user for this login and previous login. It takes into account the current session as well. Note that the velocity calculation is highly dependent on the accuracy of the location data. |
| Pre-Requisites | This rule is configured through a policy. Location database should be loaded for the rule. You might also need tools (like a browser header modifier plug-in) to simulate the different IP for the incoming session. |
| Assumptions | Location database is loaded. |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| milesPerHour | Positive number that indicates the user's speed in miles per hour. If the condition determines that user has traveled faster than this value, then condition will evaluate to true. | positive integer (default = 60) | No |
| sinceSeconds | This is a parameter that is a positive integer that specifies the time difference between this login and last login to calculate user's velocity. | positive integer (default = 172800 which is 48 hours) | No |
Possible User Scenarios
This condition can be used to determine the users's location and the risk it poses because of changes in the user's login location between the time of the current login and the last login.
One of the simplest scene is when the user is traveling by ground transportation. You can configure this rule so that 60 is the value for miles per hour and the time is in seconds for the last login (use default values).
Another case involves users traveling on air transport. You can use different values (for example, 500 miles an hour) to make sure that login locations and speed are within reason.
However, be aware that the velocity calculation depends highly on location databases.
The section provides information on the following autolearning conditions:
Entity: Entity is Member of Pattern Bucket for the first time in Certain Time Period
Entity: Entity is member of pattern less than some percent times
Entity: Entity is member of pattern bucket less than some percent with all entities in picture
Entity: Entity is member of bucket N times in a given time period
| Condition | Entity: Entity is Member of Pattern Bucket for the first time in Certain Time Period |
|---|---|
| Description | Condition to find out whether this entity is member of a pattern bucket for the first time in a certain time period. First time is a relative function. So if you want to track the first time for the membership, then in rule configuration use "Years" as the "Time period type for bucket membership" and specify a long time such as 5 years or so for the "Time period for bucket membership." |
| Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / policy. |
| Assumptions | Autolearning is enabled. |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Pattern Name | Name of the pattern for which the "first time" bucket is to be checked. | Cannot be null. | |
| Is | Evaluate this condition to true if this parameter is true and "first time" bucket is true. | Cannot be null | |
| Time period type for bucket membership | The time period type (hours, days, months, and years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
| Time period for bucket membership | The time period over which the pattern membership is evaluated. The units of time | Positive number. (Use numbers that would be valid for the time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
| Member type for pattern-bucket membership | The member type (user, device, location, city, country) | Type for members applicable for that transaction. For authentication type it is one of user, device, IP, city, state, country. | Cannot be null. |
| First time count | The count of occurrences to compare against | If you are using this rule in a Pre-Authentication (or pre-transaction) scenario, then use a value of 0 since autolearning takes place on the trailing edge of authentication or transaction. For all other checkpoints, use a value of 1 for this parameter. (1 is also a default value) | Cannot be null |
Possible User Scenarios
Examples of how to use this condition are:
To develop first time rules. For example, define a user (city for each) pattern and attach this pattern to this condition-based rule in a policy, so that when the user logs in from a city the first time, the rule will be triggered.
To challenge users when they are performing an action for the first time in transactions. For example user tried to perform a bill transfer of 5000 dollars. This can be achieved using a pattern that has user and the transaction amount ranges 1..100, 1000...10000 and so on.
| Condition | Entity: Entity is member of pattern less than some percent times |
|---|---|
| Description | Condition to find out whether this entity is member of the pattern bucket for less than a certain percent in a certain time period.This condition checks the pattern membership percentage against the pattern usage of the same entity. With this condition, the entity's membership count for percentage is counted and not the number of entities that belong to that pattern. |
| Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / policy. |
| Assumptions | Autolearning is enabled. |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Pattern Hit Percent less than | Percent hit count of the pattern that will be used for comparison | Make sure you pass "good" values. Providing values in decimal points is not recommended since the percentage values may be a Double type of values when calculated over a large number of login and pattern usage combination. For example, do not enter 10.45362. Instead enter 10.5 or 10 or 11. | Cannot be null |
| Pattern name for membership | Name of the pattern for which the membership count is to be checked. | Cannot be null | |
| Is Membership Count Less than patternHitPercent | Evaluate this condition to true if this parameter is true and the pattern percent is less than the given value | Cannot be null | |
| Time period type for pattern membership | The time period type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
| Time period for pattern membership | The time period over which the pattern membership is to be evaluated; the units of time | Positive number. (Use valid numbers depending on time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
| Member type for pattern membership | The member type (user, device, location, city, country) | Type of members applicable for that transaction. For authentication type, it is one of user, device, IP, city, state, country. | Cannot be null. |
Possible User Scenarios
This can be most effectively used in tracking the user's habits. For example, if the user usually logs in from a certain state and he starts logging in from other states also. In that case, he will be challenged on the first few times he logs in from those states since the percentage for those state will be lower than 10% (if 10 was entered as the Pattern Hit Percent less than). User (for each state) pattern can created for use in tracking the user's logins from different cities.
| Condition | ENTITY: Entity is member of pattern bucket less than some percent with all entities in picture |
|---|---|
| Description | Condition to find out whether the entity is a member of a pattern bucket some percent of time as compared to all other entities that have been member of this pattern.
This condition considers all the other entities; therefore performance is affected more than for simpler conditions. |
| Pre-Requisites | You should have entities and patterns defined before you try to add this to rule/policy. |
| Assumptions | Autolearning is enabled. |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Pattern bucket hit percent less than | Percent hit count of the pattern that will be used for comparison | Try to use a sensible number. Use 10 or 11 in place of 10.7623591 as an example. | Cannot be null |
| Pattern name for membership | Name of the pattern for which bucket percentage is checked. | Cannot be null. | |
| Is Membership Count Less than patternHitPercent | Evaluate this condition to true if this parameter is true and percentage is less than the specified percentage. | Cannot be null | |
| Time period type for pattern membership | The time period type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null. |
| Time period for pattern membership | The time period over which the pattern membership is to be evaluated. Units of time. | positive number. (Use valid numbers for the time period type). Use 0..24 for hours, use 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
| Member type for pattern membership | The member type (user, device, location, city, country) | Type of members applicable for that transaction. For authentication type it can be user, device, IP, city, state, or country. | Cannot be null. |
Possible User Scenarios
This condition can be used to find out whether users are performing actions that are not consistent with the action of other users. For example, a user is logging in from a city that most users do not log in from usually.
Non-popular states, cities, IPs, and others can be enforced using these condition.
| Condition | ENTITY: Entity is member of pattern N times |
|---|---|
| Description | Condition to find out whether this entity is a member of the pattern "n" number of times. |
| Pre-Requisites | You should have entities and patterns defined before you try to add this to rule / policy. |
| Assumptions | Autolearning is enabled. |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Pattern hit count more than | Hit count of the pattern that will be used for comparison. If hit count for the pattern is more than this value, then the condition returns true. | For Pre-Authentication execution, set the count one less than what you want the rule to trigger on. | Cannot be null |
| Pattern name for membership | Name of the pattern for which the membership count is to be checked. | Cannot be null. | |
| Is Membership Count More than patternHitCountForUser | Boolean value that is used to return true or false from the condition. It works as follows:
if (isMoreThan == true) and (hitCountMorethan returned true) then condition evaluates to true. ELSE if (isMoreThan == false) and (hitCountMorethan returned false) then condition evaluates to false. and condition evaluates to false in all other cases. |
Cannot be null | |
| Time period type for pattern membership | The time period type (hours, days, months of years) | One of wotk.type.enum. That is (hour, day, month, year) | Cannot be null |
| Time period for pattern membership | The time period over which the pattern membership is evaluated. Units of time | positive number. (Specify valid values for the time period type). Use 0 through 24 for hours, 1 through 12 for months, 1 through 31 for days, and 1 through 8 for years. | Cannot be null |
| Member type for pattern membership | The member type (user, device, location, city, country) | Type of members applicable for that transaction. For authentication type, the type can be user, device, IP, city, state, and country. | Cannot be null. |
Possible User Scenarios
Condition can be used to find out whether the user has performed a particular operation a few times and the operation is well defined. For example if user logged in from a group of IP that are tagged as anonymizer. If user logs in like that a few times, a policy can be configured to take an action.
| Condition | ENTITY: Entity is member of bucket N times in a given time period |
|---|---|
| Description | Condition to find out whether this entity has been a member of the bucket several times in a given time period. This condition can be used to check the current behavior against the pattern. Note that this is a count-based condition. So, if you configure to trigger it, for example, for a count less than three, it will trigger on the first login that matches the pattern. |
| Pre-Requisites | Ensure that the following pre-requisites are met:
|
| Assumptions | Autolearning is enabled. |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Pattern name for membership | Name of the pattern for which the bucket membership is to be checked. In the Rule's Condition tab, select the pattern from a drop-down of active patterns that will be presented. | Cannot be null. | |
| Time period for bucket membership | The time period over which the bucket membership is to be evaluated. This is in units of time. | Use 1 through 23 for hours. 1 through 30 for days. 1 through 12 for months and 1 through 8 for years. Server will use the use the max values if you enter values more than the above specified. | Cannot be null |
| Time period type for bucket membership | The time period Type (hours, days, months of years) | One of workflow.type.enum. That is (hour, day, month, year) | Cannot be null |
| Member type for pattern membership | The member Type (user, device, location [city, state, country], IP) | It is one of the type of members applicable for that transaction. For authentication type it is one of user, device, IP, city, state, country. | Cannot be null |
| Bucket hit count | The number of request for the application which will be compared against. Hit count for the bucket and the compare operator used in Entity: Entity is member of bucket N times in a given time period evaluate the outcome of the condition together. | For Pre-authentication execution set the count one less than what you want the rule to trigger on. | Cannot be null |
| Compare operator for the count | Comparison operator to be used for comparing the count in the system with bucketHitCountForEntity. For example if you specified the compare operator as "Less Than" and bucket hit count as 3, the condition will evaluate to true as long as hit count for that bucket is less than 3 for that authentication. | Possible values are from enum bharosa.numeric.eval.operator.enum
equal_to not_equal_to less_than less_than_or_equal_to more_than more_than_or_equal_to are the possible values. |
Cannot be null. |
| Return value if condition is true | Value to return if the condition evaluates to true. If condition does not evaluate to true then opposite of the success value will be returned. | True / False | Cannot be null |
| Return value if condition encounters an error | This is the value that will returned if the condition execution runs into issue. Some possible errors: the pattern is not active, the parameters that were passed (configured) are incorrect or they do not have the values in the expected range. | True / False | Cannot be null. |
Possible User Scenarios
This condition can be used to find out whether the user performed a particular operation a few times that was well defined. For example, if a user logged in from a city for a few times, the information can be used to challenge the user for the first few times.
These section provides information on the following location conditions:
| Condition | LOCATION: ASN in group |
|---|---|
| Description | Checks to see if the ASN for this IP location is in the group of ASNs that might be of interest. ASN is autonomous system number. |
| Pre-Requisites | There should a list of ASNs already defined. You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is in group | This is a boolean parameter that defines a default return value if the ASN is in the group. | [True] / False | Yes. |
| ASN in ASN group | This is a list of ASN groups. The Rule's Conditions tab will display a menu of possible ASNs groups to for this parameter. Use Group editor in OAAM Admin to edit the ASN group. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the ASN of the current activity (IP) belongs to a particular group of ASNs. For example you might have certain ASNs those can be deemed as dangerous and you may want to block users logging in from there. Or you might not want users to perform certain activity if they are logging in from an ASN that is from a particular country or region.
| Condition | LOCATION: IP in Range group |
|---|---|
| Description | Checks whether the IP of the current activity belongs to a list of IP-ranges specified. |
| Pre-Requisites | There should a group defined already which has IP-ranges as members. You should have this rule configured through a policy. |
| Assumptions | |
| Available since version | 10.1.4.5.1 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is IP in IP-range group | Use this parameter to indicate a default return value. If the IP belongs to one of the IP ranges, and this parameter is set to true, condition will evaluate to true. If IP belongs to IP range and the parameter is set to false, the condition will return false | [True] / False | Yes. |
| IP range group | Specify the group that contains the IP ranges. Condition checks if the IP belongs to one of the ranges from this group. | Yes |
Possible User Scenarios
This condition can be potentially used to determine if the IP of the current activity belongs to one of several ranges of IPs that may be of interest. For example you might have ranges of IPs from a particular subnet and you might want to take action if that is the case.
| Condition | LOCATION: In Country group |
|---|---|
| Description | Checks whether the IP belongs to a given country group. |
| Pre-Requisites | There should a group defined already which has countries as members. You should have this rule configured using some model.
IP location data is useful for this condition. (Most production environments will have application database populated) |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameters | Description | Possible Value | Can be null? |
|---|---|---|---|
| Is in group | This is a boolean parameter that defines a default return value if the country is in country group. | [True] / False | Yes. |
| Country in country group | This is a list of group of countries. The Rule's Condition tab will display a drop-down of possible groups.
Use the Group editor in OAAM Admin to edit the group. |
(java Long values) | Yes |
Possible User Scenarios
This condition can be potentially used to find out if the current activity seems to originate from one of several countries of interest. For example you might have a list of countries and if the current IP used for the activity belongs to one of those countries, then you can configure the policy to take an action or generate an alert.
| Condition | LOCATION: IP Connection type in group |
|---|---|
| Description | Find out whether the connection type of this IP location is in the group of connection types that might be of interest. |
| Pre-Requisites | There should a list of connection types already defined. You should have this rule configured using policies. |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is in group | This is a boolean parameter that defines a default return value if the IP's connection type is really in connection type group. | [True] / False | Yes. |
| Connection type in group | This list of connection type groups. The Rule's Condition tab will display a drop-down of possible lists of connection types. Use group editor in administration user interface to edit this group list. | Yes |
Possible User Scenarios
This condition can be used to find out whether the IP of the current activity comes from a connection type that can be of particular interest to determine fraud. For example, you might have connection type of "satellite link."
| Condition | LOCATION: IP line speed type |
|---|---|
| Description | Checks whether the current IP has connection line speed as one of the specified connection speed. This (connection speed) is categorized into High, Medium, Low or Unknown |
| Pre-Requisites | You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated) |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| is | This is a boolean parameter that defines a default return value if the connection speed is the one specified. | [True] / False | Yes. |
| speed type | This is the enumeration value that indicates connection speed type. This (connection speed) is categorized into High, Medium, Low or Unknown
The enum that is used for this parameter is location.linespeed.enum |
(Integer) Default value is location.linespeed.enum.low | Yes |
Possible User Scenarios
This condition can be used potentially to find out whether the current activity seems to originate from an IP that has a particular speed type. For example, you may want an alert generated if the speed type is high for the user who usually logs in from a dial-up network.
| Condition | LOCATION: IP Routing Type in group |
|---|---|
| Description | Checks to see if the IP Routing Type is in the group. |
| Pre-Requisites | There should a group defined already which has routing types as members. You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated) |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is in group | This is a boolean parameter that defines a default return value if the IP routing type is in group. | [True] / False | Yes. |
| Routing type in group | This is a list of groups of IP routing types. A drop-down of possible lists of IP routing type groups. Use the Group editor in OAAM Admin to edit this group list. | (java Long values) | Yes |
Possible User Scenarios
This condition can be potentially used to find out whether the current activity is from an IP that belongs to a particular routing type. For example, you might have a list of routing types that can potentially lead to fraud and if the current IP of the activity has one of those routing types, you can configure to take an action or generate an alert.
| Condition | LOCATION: Carrier in group |
|---|---|
| Description | Checks to see if the IP is in the given carrier group |
| Pre-Requisites | There should a list of carriers already defined. You should have this rule configured using a policy. Location data is helpful for the condition. |
| Assumptions | |
| Available since version | |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is in group | This is a Boolean parameter that defines the return value if the carrier is in group or not. | [True] / False | Yes. |
| IP in carrier group | This is a list of the groups of carriers. The Rule's Condition tab displays drop-down of possible lists of carriers groups to configure for this parameter. Use the Group editor in OAAM Admin to edit carrier group. | Yes |
Possible User Scenarios
This condition can be potentially used to check to see if the carrier of the current activity (IP) belongs to a particular list of carriers. For example you might have certain carriers that can be deemed as "dangerous" (hackers stole all of a carrier's phone numbers recently) and you may want to block users logging in from a carrier, or you might not want users to perform a certain activity if they are logging in from a carrier that is from a particular country or region.
| Condition | LOCATION: IP Maximum Users |
|---|---|
| Description | Condition checks to see if the maximum number of distinct users using the current IP address within the given time duration exceeds the configured condition attribute value. Notice that the current request is also counted in finding the number of unique users from the IP. |
| Pre-Requisites | You should have this rule configured using a policy. |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Seconds elapsed | This is the time period in which the number of users from this IP is to be counted. | integer [Default = 300] | No |
| The maximum number of users | Maximum number of users allowed. | integer [Default = 5] | No |
Possible User Scenarios
This condition can be used to find out if a particular IP is being used by fraudsters to perform logins / transactions by using different login IDs they have stolen. In such cases you will see a number of different logins from the same IP during a relatively short period.
| Condition | LOCATION: Is IP from AOL |
|---|---|
| Description | Find out whether the IP is from AOL proxy |
| Pre-Requisites | You should have this rule configured using a policy to test it. |
| Assumptions | |
| Available since version | |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is AOL | This is the default return value is IP is indeed from AOL. If the IP is not from AOL then opposite of this attribute is returned. | Boolean [true] / false | No |
Possible User Scenarios
This condition can be used to figure out if the IP is from an AOL proxy. Customers may want to set up the system to take certain actions for users logging in from AOL.
| Condition | LOCATION: in city group |
|---|---|
| Description | Checks whether the current activity belongs to a given city group. |
| Pre-Requisites | There should a group defined already which has cities as members. You should have this rule configured using a policy. IP location data is useful for this condition. (Most production environments will have IP location database populated) |
| Assumptions | |
| Available since version | |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is in group | This is a Boolean parameter that defines a default return value if the city is really in country group. | [True] / False | Yes. |
| City in city group | This is a list of city groups. The Rule's Conditions tab displays a drop-down of possible groups of cities. Use group editor in admin user interface to edit this group list. | (java Long values) | Yes |
Possible User Scenarios
This condition can be used to figure out if the current activity seems to originate from one of several cities of interest. For example you might have a list of cities and if the current IP of the activity occurs in one of those cities, you can configure the system to take an action or generate an alert.
These section provides information on the following transaction conditions:
Transaction: Check Current Transaction Using Filter Condition
Transaction: Check Transaction Aggregrate and Count Using Filter Conditions
Transaction: Check Count of any entity or element of a Transaction using filter conditions
Transaction: Check if consecutive Transactions in given duration satisfy the filter conditions
Transaction: Compare Transaction Aggregrates (Sum/Avg/Min/Max) across two different durations
Transaction: Compare Transaction counts across two different durations
Transaction: Compare Transaction Entity/Element counts across two different durations
Note:
The filter operators "like" and "not like" work only on transaction data and entity data where the data type is string.| Condition | TRANSACTION: Check Current Transaction Using Filter |
|---|---|
| Description | Check to see whether the current transaction matches ALL the conditions specified. Up to 6 conditions can be specified. |
| Pre-Requisites |
|
| Assumptions | If there are multiple transactions in the current session, then this condition is applied on the last transaction |
| Available since version | 10.1.4.5.1 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions | No | |
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, an appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on checks on the current transaction.
For example, you have configured a transaction called purchase and you want to trigger a rule whenever the amount field of the purchase transaction is greater than 1000 and country is in the list of High Risk countries (that you have configured).
For achieving this, you must use this rule with two filter conditions: one for checking if the amount field is greater than 1000 and the second filter condition for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions on the current transaction.
| Condition | TRANSACTION: Check Transaction Count Using Filter |
|---|---|
| Description | Check the transaction count with a specified value. You can specify the criteria for the transaction to be counted using the filter conditions (up to 6 conditions) and you can also specify the other parameters like the duration to be considered and the transaction status to consider etc. |
| Pre-Requisites |
|
| Assumptions | If there are multiple transactions in the current session, then this condition is applied on the last transaction |
| Available since version | 10.1.4.5.1 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction type of the transaction to be counted. It represents the Transaction Definition fully qualified key. This is specified using the list box that has the list of transaction definitions | No | |
| specifiedConditionEnumForCount | Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals | No | |
| specifiedValueForCount | Transaction count numeric value to check | No | |
| durationDescriptor | Specify the duration during which the transactions have to be counted. The duration descriptor enables you to specify the duration.
Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backward to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backward to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days. |
No | |
| transactionStatusEnum | Specify the transaction status that has to be considered for counting.
Do not specify any status if you want to consider all transactions regardless of their status. |
Yes | |
| ignoreCurrentTransactionInCount | Specify if you want to ignore the current transaction (if any) in the count.
If there are multiple transactions and if this is specified as true, only the last transaction is ignored. |
Yes | |
| applyFilterOnCurrentTransaction | Specify if you want to check the filter conditions on the current transaction before performing the count.
If the filter conditions fail on the current transaction, then the rule condition is evaluated to false without performing the count. |
||
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on transaction count condition.
For example, suppose you have configured a transaction called "purchase" and you want to challenge the user if the user is performing a lot of purchases (for example more than 2 per hour with amount greater than 1000 for each purchase) from a high risk country, you may want to use this condition.
For achieving this, you must use this rule with the following:
Specify Count condition as '"Greater Than Equals."
Specify Count to check as "2."
Specify the duration with durationType as rolling and duration as 1 hour.
Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in count.
Specify true for "Apply FilterOnCurrentTransaction?" field.
Configure two filter conditions:
One for checking if the amount field is greater than 1000.
Another for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting.
| Condition | TRANSACTION: CheckTransactionAggregrateAndCountUsingFilter.xml |
|---|---|
| Description | Check the aggregrate of a numeric field and transaction count. You can specify the criteria for transaction to be counted using the filter conditions (up to 6 conditions) and you can also specify the other parameters like duration to be considered and the transaction status to consider etc. |
| Pre-Requisites | Transactions should be defined.
Transaction type of the current transaction should be same as the transaction type specified in the rule condition |
| Assumptions | Aggregrate can be applied only on numeric fields. So the transaction definition should have at least one numeric field. |
| Available since version | 10.1.4.5.1 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| aggregrateFunctionEnum | Aggregrate function to check. Available functions are sum, min, max, avg | ||
| elementDefFQKey | Numeric element on which aggregrate check has to be performed. It represents fully qualified key of the numeric field. This is specified using list box that has list of all numeric data fields. | No | |
| specifiedConditionEnumForAggregrate | Operator to be applied for the aggregrate condition. Specify greater than, greater than or equals, less than, less than or equals | No | |
| specifiedValueForAggregrate | Aggregrate numeric value to check | No | |
| specifiedConditionEnumForCount | Operator to be applied for the count condition. Specify greater than, greater than or equals, less than, less than or equals | Yes | |
| specifiedValueForCount | Transaction count numeric value to check | Yes | |
| durationDescriptor | Specify the duration during which the transactions have to be counted. The duration descriptor enables you to specify the duration.
Important: By default, durationType is "rolling," meaning it takes the current time as the end point to count backward to the start point. Whenever the duration is described as "last" x seconds/minutes/hours/days, the rolling type duration has to be used. So if you specify 1 day using "rolling" durationType, the "rolling" day starts 24 hours (exactly 1 day) from the current time. For example, if it is 11:33 am, and you specify 1 day, the "rolling" day will start from 11:33 am of the previous day and end at the current time today. There will be occasions where you want to have the duration window start at 0.00. For those occasions, you should use the durationType as "calendar". So if you specify 1 day using "calendar" as the durationType, the "calendar" day will start at 0.00 (12:00 am) of that day and end at the current time. Examples of "rolling" and "calendar": A "calendar" week starts from Sunday regardless of the current day, whereas the "rolling" week starts from 7 days from the current day. A "calendar" month starts from the 1st of the current month, whereas the "rolling" month starts from the same day of the previous month. A "calendar" year starts from January 1st of the current year, whereas the "rolling" year starts from the same day of the previous year. In both the "calendar" and "rolling," the end date/time is the current time. The durationType affects how the startTime of the duration is computed. The "Before" option is used when you want to skip over an interval of time before you begin counting backward to the start point. For example, if you want to calculate 7 days worth of data, but you do not want the data from the last 7 days, you would specify the interval of time you want to skip. If today is February 6, and you want to look at data from January 17 to the 23rd, you would specify "Before" 15 days. |
No | |
| transactionStatusEnum | Specify the transaction status that has to be considered for counting. If you want to consider all transactions regardless of their status, do not specify any status | Yes | |
| ignoreCurrentTransactionInCount | Specify if you want to ignore current transaction (if any) in the count. If there are multiple transactions and if this is specified as true, only the last transaction is ignored. | Yes | |
| applyFilterOnCurrentTransaction | Specify if you want to check the filter conditions on the current transaction before performing the count. If the filter conditions fail on the current transaction then the rule condition is evaluated to false without performing the count. | ||
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. The left hand side represents the fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. |
||
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. The operator and the right hand side represent the fully qualified key of the filter condition.
The right hand side is the value, which could be a simple value, the value of the current transaction, or a group.
|
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on aggregrate of a transaction numeric value and transaction count.
This is designed to reduce the number of conditions since you can specify checks for both aggregrate and count in a single condition
For example, suppose you have configured a transaction called purchase and you want to challenge if a user is performing a lot of purchases (for example, more than 2 per hour with average amount that is greater than 500) from a high-risk country.
For achieving this, you must use this rule with the following:
Specify Aggregrate condition as "Average."
Specify Aggregrate value to check as "500."
Specify Count condition as "Greater Than Equals."
Specify Count to check as "2."
Specify the duration with durationType as rolling and duration as 1 hour.
Specify false for "Ignore Current Transaction in count?" since you want to consider current transaction in the count.
Specify true for "Apply FilterOnCurrentTransaction?" field.
One filter condition: for checking if the country of the current session is in the list of High Risk countries.
This condition can be used to specify up to six (6) filter conditions that are applied on transactions that are considered for counting
| Condition | TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions |
|---|---|
| Condition | TRANSACTION: Check Count of any entity or element of a Transaction using filter conditions |
| Description | Check to see whether the count of a transaction entity or entity/data element with a given count where transactions matches ALL the conditions specified. Up to 6 conditions can be specified. |
| Pre-Requisites | Ensure that you are using 10.1.4.5.2 or later.
Transactions should be defined; Transaction type of the current transaction should be same as the transaction type specified in the rule condition |
| Assumptions | |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
| elementDefFQKey | Transaction Entity/Element that must be counted for checking | No | |
| durationDescriptor | Duration Descriptor | No | |
| forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
| ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored in the count | ||
| specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
| specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
| applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the count of an entity or entity/data element of the transaction.
For example, you have configured a transaction called "purchase" and you want to trigger a rule if the same user is trying to use more than 5 different credit cards in the last 2 hours and the amount of purchase is more than $100.
To achieve this:
Select the "Credit Card" "Entity" name as the one to be counted, so that the rule counts the distinct number of credit cards used.
Then, select "For the same current user" flag as true.
Then, select the duration as 2 rolling hours and the filter condition as "Amount" greater than 100.
There is provision to specify up to six (6) conditions for filtering the transactions that need to be considered for counting.
| Condition | TRANSACTION: Check if consecutive Transactions in given duration satisfy the filter conditions |
|---|---|
| Description | Check to see whether consecutive transactions in a given duration satisfy the specified filter conditions |
| Pre-Requisites |
|
| Assumptions | |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
| durationDescriptor | Duration Descriptor | No | |
| transactionStatusGroupId | Group of Transaction Statuses that should be considered. If no group is specified then Transaction Status is ignored in the query. | Yes | |
| ignoreCurrentTransactionInQuery | Flag to indicate if the current transaction has to be ignored | ||
| forTheSameCurrentUserId | Flag to indicate if only transactions belonging to the current user to be counted.
If this flag is false then transactions irrespective of users will be considered. |
No | |
| allowGapsForChecks | Flag to indicate if gaps are allowed while checking for conditions.
If this value is TRUE then gaps would be allowed while checking for conditions. |
No | |
| noOfTransactionsToCheckFor1stCheck | Number of transactions that should satisfy the 1st check. Specify positive integers. | No | |
| filter101Key
filter102Key filter103Key filter104Key filter105Key filter106Key |
Filter Keys for 1st check.
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
| filter101Condition
filter102Condition filter103Condition filter104Condition filter105Condition filter106Condition |
Filter Conditions for 1st check.
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified | |
| noOfTransactionsToCheckFor2ndCheck | Number of transactions that should satisfy the 2nd check. Specify positive integers. | No | |
| filter201Key
filter202Key filter203Key filter204Key filter205Key filter206Key |
Filter Keys for 2nd check.
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field. This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
||
| filter201Condition
filter202Condition filter203Condition filter204Condition filter205Condition filter206Condition |
Filter Conditions for 2nd check.
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition. Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on checks that are satisfied on consecutive transactions in a given duration.
For example, you have configured a transaction called purchase and you want to trigger a rule if the current/last transaction amount is greater than $1000 and there were at least 3 transactions before that where the amount was less than $10.
So, the rule is looking at the last 4 transactions and checking for a fraud pattern of small transactions first and then a big transaction.
Configure a rule with this rule condition and select the appropriate transaction type.
Select the number of transactions for the first check as "1" and select the condition to check as "Amount" "Greater Than" 1000, since you want to check only one transaction for the large amount.
Select the number of transactions for the second check as "3" and select the condition to check as "Amount" "Less Than" 10, since you want to check 3 transactions for smaller amounts.
If you want to allow other transactions in between the checks for the first check and the second check, select "Allow Gaps in Transactions during checks?" as TRUE otherwise select FALSE.
| Condition | TRANSACTION: Compare Transaction Aggregrates (Sum/Avg/Min/Max) across two different durations |
|---|---|
| Description | Compare transactions aggregrates across two different durations |
| Pre-Requisites |
|
| Assumptions | |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
| aggregrateFunctionEnum | Aggregrate function that has to be used | No | |
| elementDefFQKey | Transaction Entity/Data Element that must be aggregrated | No | |
| durationDescriptorFor1stDuration | Select duration for the first aggregrate | No | |
| durationDescriptorFor2ndDuration | Select duration for the second aggregrate | No | |
| comparisonConditionEnum | Comparison condition | No | |
| multiplierFor2ndDurationValue | Multiplier value for the second aggregrate. Only non-zero and null values will be considered | Yes | |
| forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
| ignoreCurrentTransactionInQuery | Flag to indicate if the current transaction has to be ignored | No | |
| specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
| specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
| applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of aggregrates of a transaction entity/data element across two different durations.
For example, you have configured a transaction called purchase and you want to trigger if the sum of the transaction amount for the current day is 20% more than the sum of all transactions amount of the previous day for that user.
To achieve this:
Select the "Amount" as the element to be aggregrated and "Sum" as the aggregrate function.
Then, select first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.
Then select the comparison condition as "Greater than" and multiplier value as 1.2 (100%+20%).
| Condition | TRANSACTION: Compare Transaction counts across two different durations |
|---|---|
| Description | Compare transactions counts across two different durations |
| Pre-Requisites |
|
| Assumptions | |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| trxDefKey | Transaction Definition fully qualified key. This is specified using list box that has list of transaction definitions | No | |
| durationDescriptorFor1stDuration | Select duration for the first count | No | |
| durationDescriptorFor2ndDuration | Select duration for the second count | No | |
| comparisonConditionEnum | Comparison condition | No | |
| multiplierFor2ndDurationValue | Multiplier value for the second aggregrate. Only non-zero and null values will be considered | Yes | |
| forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
| ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored | No | |
| specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
| specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
| applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of transaction counts across two different durations.
For example, you have configured a transaction called "purchase" and you want to trigger if the number of transactions for the current day is 20% more than the number of all transactions of the previous day for that user.
To achieve this:
Select the first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.
Then, select the comparison condition as "Greater than" and multiplier value as 1.2 (100%+20%).
| Condition | TRANSACTION: Compare Transaction Entity/Element counts across two different durations |
|---|---|
| Description | Compare transaction entity/element counts across two different durations |
| Pre-Requisites |
|
| Assumptions | |
| Available since version | 10.1.4.5.2 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| durationDescriptorFor1stDuration | Select duration for the first count | No | |
| durationDescriptorFor2ndDuration | Select duration for the second count | No | |
| comparisonConditionEnum | Comparison condition | No | |
| multiplierFor2ndDurationValue | Multiplier value for the second aggregrate. Only non-zero and null values will be considered | Yes | |
| forTheSameCurrentUserId | Boolean flag to indicate whether only transactions belonging to the current user to be counted or not | Yes | |
| ignoreCurrentTransactionInCount | Flag to indicate if the current transaction has to be ignored | No | |
| specifiedConditionEnumForCount | Condition for the count check. Select only valid operators that are relevant to numeric values | No | |
| specifiedValueForCount | Count value to check. Specify only valid positive integers. | No | |
| applyFilterOnCurrentTransaction | Flag to indicate if the filter conditions have to validated on current transaction before doing the count | No | |
| filter1Key
filter2Key filter3Key filter4Key filter5Key filter6Key |
These parameters specify the left hand side of the filter conditions. It represents fully qualified key of the transaction field.
This field could be an entity field or data field or transaction attribute or request attribute. Note: There is a widget for this that renders list box with all the data fields. |
Yes | |
| filter1Condition
filter2Condition filter3Condition filter4Condition filter5Condition filter6Condition |
These parameters represent the operator and right hand side of the filter condition. It represents fully qualified key of the filter condition.
Note: There is a widget for this that renders the list box of operators and a way to specify simple value or group name (in case of IN or NOT IN operator) or select another field in the transaction. |
Wherever the filterKey is specified, appropriate condition has to be specified |
Possible User Scenarios
This condition can be used whenever you want to trigger a rule based on the comparison of any transaction entity/element counts across two different durations.
For example, you have configured a transaction called "purchase" and you want to trigger if the number of distinct credit cards used in the current day is 20% more than the number of distinct credit cards used on the previous day for that user.
To achieve this:
Select "Credit card" as the element to be counted and select the first duration as 1 calendar day and the second duration as 1 calendar day before 1 day.
Then, select the comparison condition as "Greater than" and the multiplier value as 1.2 (100%+20%).
The following in-session conditions are documented in this section:
| Condition | Session: Check param value |
|---|---|
| Description | Check to see whether the specified parameter value is above the given threshold. This condition can be used to find out whether the value of a particular parameter in the transaction is above some known threshold and then action can be taken accordingly. Basically provided a mathematical function for integrators. This will be very useful in native integration. |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is | If the "Is" is true and the value is above the threshold provided then condition evaluates to true.
If the "Is" is false and the value is below the threshold provided then condition evaluates to true. |
[True] / False | No |
| ValueKey | The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditcard" and whose value at Checkpoint is going to be populated by users credit card, then key is "creditcard" in this case. If key is null then defaultError return value is the result of the condition. | Yes | |
| ValueAbove | This is basically the threshold value. A string that can be parsed into a number. (all numeric characters and "+", "-" and "." Also time can be used here in "HH24:MM:SS:MS" format. This can be used to see if the time is greater than the time parameter present in the transaction. | Yes |
This condition can be used whenever you want to find out whether the value of a particular attribute of the transaction exceeds some threshold.
For example, you have configured a transaction called purchase and you want to trigger a rule whenever the customer purchase exceeds 1000$ mark.
For achieving this, you must use this rule with this condition.
Configure the "ValueKey" of your transaction = "purchase.orderTotal" assuming that you have such an attribute in your transaction.
Configure "ValueAbove" = "1000". Configure an alert that says "Too Big Purchase"
Process a transaction by providing some total value numbers above 1000 and some below 1000.
Verify that for the ones above 1000 the rule is triggered.
| Condition | Session: Check param value for regex |
|---|---|
| Description | Find out whether the specified parameter value matches regular expression. This condition can be used to find out whether some string value of a particular parameter in the transaction matches some known pattern and then action can be taken accordingly. Basically provided some mathematical function for integrators. This will be very useful in native integration. |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
| Parameter | Description | Possible Values | Can be Null? |
|---|---|---|---|
| Is | If the "Is" is true and regular expression matches to the provided criteria then condition evaluates to true.
If the "Is" is false and regular expression does not match to the provided criteria then condition evaluates to true. |
[True] / False | No |
| ValueKey | The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditcard" and whose value at Checkpoint is going to be populated by users credit card, then key is "creditcard" in this case. If key is null then defaultError return value is the result of the condition. You should be able to find this key in the Internal ID column in Transaction Source Data tab in transaction details. | Yes | |
| Regular Expression | The character pattern with which you want to match the "value" whose look up name is given by "ValueKey". In same credit card example. We want to check to see whether the user entered all correct in credit card so we might look for pattern "[0-9]". | Yes | |
| Error Return value | If there is any error then return (evaluate to) this value. If this value is not specified (null) then "False" is assumed. | [False] / True | Yes |
This condition can be used whenever you want to find out whether the value of a particular attribute of the transaction matches some character pattern.
For example, you have configured a transaction called "purchase" and you want to trigger a rule whenever the customer email field ends with ".gov" or ".mil" so you can track government and military business for your firm.
For achieving this, you must use this rule with this condition.
Configure the "ValueKey" of your transaction = "customer.email" assuming that you have such a attribute in your transaction.
Configure "Regular Expression" = "*[.gov][.mil]". Configure an alert that says "Goventment/Military business."
Process some transaction by providing some email address ending with ".gov" or ".mil". Verify that the alert is generated.
Process some transactions by giving another email address ending ".com" or any ending other than ".gov" or ".mil". Notice that alert is not generated.
| Condition | Session: Check param value in group |
|---|---|
| Description | Checks to see if specified parameter value matches the regular expression and the group identified by the expression matcher is in the list of strings. Regular expression matching is not sensitive to case (uppercase and lowercase letters are treated same) |
| Pre-requisites | None for condition as such, but you must have a rule configured with this condition for it to work. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All checkpoints. |
Parameters
| Parameter | Description | Possible Value | Can be Null |
|---|---|---|---|
| Is | If the "Is" is true and the key's value matches the regular expression and the first group string found by the regex matcher is in the string group, then the condition evaluates to "true." | [True] / False | Yes |
| Parameter Key | The "key" or the look up name of the parameter in the transaction. For example, if the transaction is "internet banking" and the name of the attribute is "bankName" and its value at checkpoint is to be populated by users, then key is "Transaction.bankName" in this case. You should be able to find this key in the Internal ID column in the Transaction Source Data tab in transaction details. If the key is null, then defaultReturnValue is the result of the condition. | Yes | |
| Regular Expression | The character pattern with which you want to match the "value" which has its look up name given by "Parameter Key". In same banking example, if we want to find out whether the bankName equals "SomeBank," we should define this pattern in the policy/rule as "(SomeBank)" without the quotation marks. If the regular expression is null, then defaultReturnValue is the result of the condition. | Yes | |
| In list | The condition checks to see if the character group obtained by the regular expression matcher belongs to this string group. If the list name is null or if the list specified by the name is empty, then defaultReturnValue is the result of the condition. | Yes | |
| Default Return value | If there is any error or if the condition cannot be evaluated because of insufficient data, then return (evaluate to) this value. If this value is not specified (null) then "False" is assumed. | [False] / True | Yes |
Possible User Scenarios
This condition can be used whenever you want to find out whether some part of the value of a particular attribute of the transaction matches some character pattern, and to see if this part of the value is present in the pre-determined group of strings.
For example, you have configured a transaction called internet banking and you want to trigger a rule if the bank name is "bank1" or "bank2."
To achieve this, you must use this rule with this condition:
Configure the "Parameter Key" of your transaction = "Transaction.bankName" (assuming that you have such an attribute in your transaction).
Configure "Regular Expression" = "(bank.)". Configure some alert that says "Some specified bank transaction".
Create a group of generic strings called "interesting banks" and add "bank1" and "bank2" to it.
Configure the group name as "In List" parameter for this condition.
Configure "Is" = true and default return value = false.
Process some transaction by providing some bank names that are "bank1" and "bank2","bank3", and so on. Verify that the alert is generated for "bank1" and "bank2" only.
Verify that alerts will also be generated for "BANK1". This is to demonstrate that the regular expression matching is not case-sensitive.
| Condition | Session: Check string value |
|---|---|
| Description | Check to see whether the specified parameter value is equal to given character string. This condition can be used to find out whether the value of a particular parameter in the transaction matches an expected string and then action can be taken accordingly. Basically provided some string equality function for integrators. This will be very useful in native integration.
Note that comparison is case-sensitive. That is "Good" is not equal to "GOOD". |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| ValueKey | The "key" or the look up name of the parameter in the transaction. For example if the transaction is purchase and the name of the attribute is "creditCardType" and whose value at Checkpoint is going to be populated by users credit card type, then key is "creditCardType" in this case. | Yes | |
| StringValue | This is basically the value to compare with. | Yes |
This condition can be used whenever you want to find out whether the value of a particular attribute of the transaction equals a given string.
For example, you have configured a transaction called purchase and you want to trigger a rule whenever the customer credit card is American Express.
For achieving this, you must use this rule with this condition:
Configure the "ValueKey" of your transaction = "purchase.creditCardType" assuming that you have such an attribute in your transaction.
Configure "StrValue" = "AMEX". Configure some alert that says "Amex Card Used"
Process some transaction by providing the card type as AMEX and some with other card type.
Verify that for using AMEX the rule is triggered.
Table B-1 Day of Week
| Condition | Day of Week |
|---|---|
|
Description |
Checks to see if time unit in current date matches some criteria. The condition determines if a particular time unit (that is part of the current time) belongs to a particular position in the time unit. This condition uses the request date if available to evaluate the date function requested with the help of parameters. If the request date is not available, then current server date time will be used. |
|
Example |
This condition can determine if the day of the week is equal to (or not equal to or …) Monday or Tuesday and so on. It can also determine if the day of the month matches certain criteria of the day of the month. It can also try to match the same criteria if month of the year is X or not X or in or not in X. |
Parameters
| Parameters | Description | Possible Values |
|---|---|---|
| Time Unit | Enum
What is the time unit you are looking for? The default value is Day Of The Week |
Possible values are:
|
| Comparison operator | Enum
What comparison you want to make with the time unit. The default value=Equal To |
Possible values are:
|
| Comparison value | String
The default value = "" (empty string), that represents integer or string that represents comma separated integers. Example: "1" or "1,2,3,4". The user can use comma-separated values when using IN or NOT in operator. If comma-separated values are used for any other operators, it will be determined as an error and value of the number 5 parameter (shown in Error Return) will be returned. If the string does not represent number (or a list of comma separated numbers) then it is determined as error and value of parameter number 5 will be returned. |
Correct values of this parameter for different time units.
|
| IS Condition True | Boolean
Default value = true This will the return value if the comparison is true. |
|
| Error Return value | Boolean
Default value = false If the user has configured the value of Comparison Value (#3) incorrectly, or if there is any other error determining date then this value will be returned. The days of the weeks are:
The week day is 2,3,4,5,6 Time Unit = Day of the Week Comparison Operator = "IN" Comparison Value = "1,2,3,4,5" Is Condition True = true Error Return value = "false" |
The following transaction conditions are documented in this section:
| Condition | System - Check Boolean Property |
|---|---|
| Description | Verify if specified property equals true of false. |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| Property | The complete name of the property that must be checked. | Yes | |
| PropertyValue | The expected value of the property. If the property has this value then the condition will evaluate to true. | [True] / false | Yes |
| Defaultvalue | The value of the property to be used if the property is not found in the system. | [True] / false | Yes |
This condition can be used whenever you want to find out whether the value of a particular property equals true or false.
For example, you have a property "trigger.sample.rule" and its value is true.
You want to trigger some rule based on this property.
For achieving this, you must use this rule with this condition.
Configure the "Property" of this condition = "trigger.sample.rule". Configure the PropertyValue = "true". Configure DefaultValue = "false"
Run authentication of users to see if the rule triggers.
Then, go to property editor and change the value of the property "trigger.sample.rule" to false.
Run authentication of users again and notice that the rule does not trigger.
| Condition | System - Check Integer Property |
|---|---|
| Description | Verify if specified property equals expected integer value |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| Property | The complete name of the property that must be checked. | Yes | |
| PropertyValue | The expected value of the property. If the property has this value then the condition will evaluate to true. | Integer | Yes |
| Defaultvalue | The value of the property to be used if the property is not found in the system. | Integer | Yes |
Possible Scenarios
This condition can be used whenever you want to find out whether the value of a particular property equals expected integer value.
For example, you have a property "trigger.sample.rule.test.integer" and its value = 25.
You want to trigger some rule based on this property.
For achieving this, you must use this rule with this condition.
Configure the "Property" of this condition = "trigger.sample.rule.test.integer". Configure the PropertyValue = "25". Configure DefaultValue = "30"
Run some authentication users to see the rule triggers.
Then go to property editor and change the value of the property "trigger.sample.rule.test.integer" to 88.
Run some authentication users again and notice that the rule does not trigger.
| Condition | System - Check String Property |
|---|---|
| Description | Verify if specified property equals expected string value |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| Property | The complete name of the property that must be checked. | Yes | |
| PropertyValue | The expected value of the property. If the property has this value then the condition will evaluate to true. | String | Yes |
| Defaultvalue | The value of the property to be used if the property is not found in the system. | String | Yes |
Possible User Scenarios
This condition can be used whenever you want to find out whether the value of a particular property equals expected the string value.
For example, you have a property "trigger.sample.rule.test.string" and its value = "test_string".
You want to trigger a rule based on this property.
For achieving this, you must use this rule with this condition.
Configure the "Property" of this condition = "trigger.sample.rule.test.string". Configure the PropertyValue = "test_string" and configure DefaultValue = "some_other_string"
Run authentication on users to see the rule triggers.
Then go to Property editor and change the value of the property "trigger.sample.rule.test.instringteger" to "completely different string value".
Run authentication of users again and notice that the rule does not trigger.
| Condition | System - Check Request Date |
|---|---|
| Description | Verify if the request date of the transaction or authentication is after a specific date. Notice that only the year, month and day part of the date is used. So basically the "time" portion of the date is ignored when comparing dates. |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| Date (MM/dd/yyyy) | The date string which user wants to check the request date against. | No | |
| Is After Request Date | To check to see whether the request date is after the specified date or not after specified date. | [True] / False | Yes |
Possible User Scenarios
This condition can be used whenever you want to find out whether the transaction or authentication occurred after a certain date.
For example, you want to direct users to certain other policy after given date, and then you can use this rule.
For achieving this, you must use this rule with this condition.
Configure the "Date" of this condition = "12/22/2009" if you want to trigger rule starting 23rd December of 2009. Configure the "Is After"= "true".
Run some authentication on users. If the date is after 12/22/2009 the rule should trigger.
Then go to the Policy editor and change the date in this condition to a future date.
Run some authentication on the users again and notice that the rule does not trigger.
The following user conditions are documented in this section:
| Condition | User: Check User Data |
|---|---|
| Description | Verify if specified key has any related data for the user |
| Pre-Requisites | None for condition as such. But you must have rule configured with this condition to experience the behavior. |
| Assumptions | |
| Available since version | 10.1.4.5 |
| Checkpoints | All Checkpoints. |
Parameters
| Parameter | Description | Possible Value | Can be Null? |
|---|---|---|---|
| User Data Key | The complete name of the key which may have associated data for that user.
Consider this a property or a configuration property for only that user. |
[Strings] Default= email | Yes |
Possible User Scenarios
This condition can be used whenever you want to check to see whether the user has an associated data for the key.
For example, you want to find out whether the user has an email defined in his OTP configuration.
You want to trigger some rule based on whether this email field is defined (non-empty) for the user.
For achieving this, you must use this rule with this condition.
Configure the "User Data Key" of this condition = "user_otpContactInfo_email" (for mobile phone, use key="user_otpContactInfo_mobile").
Use the new out-of-the-box base models that are shipped with 11g. This will force user to register for OTP on first or second login.
Run some authentications with the registered users and you can see the rule triggering when they are registered for the OTP email (or mobile if you have used that as key).
Then go to policy editor and change the value of the key "zoom.some.garbage.that.is.not.supposed.to.exist"
Run some authentication users again and notice that the rule does not trigger. (assumption no such key data exists for this weird looking key)
| Condition | User: Stale Session |
|---|---|
| Description | Verify if a newer session is established after this session is created |
| Pre-Requisites | None for condition as such. But you must have a rule configured with this condition to experience the behavior. |
| Assumptions | ___________ |
| Available since version | 10.1.4.5 |
| Checkpoint | All checkpoints. |
Possible User Scenarios
This condition can be used whenever you want to find out whether the user has established a successful login from another channel while this authentication is in progress.
You want to trigger a rule, or an alert, or a rule and an alert based on that.
To achieve this, you must use this rule with this condition. Configure this rule for the post-authentication checkpoint.
Perform log in (for already the registered user) from one browser window (for example, Firefox) and be in the process where you are shown a password pad.
Then, open another browser (for example, Windows Internet Explorer) and perform another login for the same user and complete the login process. Do not log out yet.
When you come back to the first browser and complete the login, you should see this rule triggered.
|
 Copyright © 2009, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
