B Pattern Processing

Autolearning is the application of several Oracle Adaptive Access Manager features to dynamically profile behavior of user, device, locations, and transaction entities. Patterns are defined by an administrator to automatically capture behavior. These patterns are in turn used by Oracle Adaptive Access Manager to dynamically create and populate buckets based on the pattern parameters. Oracle Adaptive Access Manager automatically records/maintains the bucket memberships of the users/devices/locations/entities over time so that the overall profile can be used to evaluate risk. As well, dynamic actions are used to populate groups based on rule outcomes to further profile behavior. The memberships of these automatically managed groups are also used to evaluate risk.

This appendix provides information about autolearning pattern data processing.

B.1 Pattern Data Processing

If the system load is light and if the pattern is configured, the data will be processed as soon as the clients calls the API that is used for triggering the data processing. The system load is the number of authentication, transaction, rule processing (and other) reports and requests served by the Oracle Adaptive Access Manager server.

The logic for processing the data is as follows.

For each (successful) transaction record, the following process occurs:

Gather all the attributes of the transaction from the database.
Determine the transaction type and if any of the patterns have the same transaction type as the one you have at hand.
If there are no patterns having the same transaction type as the one at hand, the process is stopped at this point and returns to the caller with nothing.
If there are patterns that have the same transaction type as the one at hand, then the following process is performed for each pattern.
1. Get the parameters for that pattern and determine if the parameter values for the transaction at hand satisfy the requirements (like range for example). If not, move to next pattern.
2. If the parameters satisfy the requirements, then go to the fingerprint table.
3. If the fingerprint exists for such a combination, then go ahead and update the counters in workflow tables (hour, day, month, year) for entities added to the pattern.
4. If the fingerprint does not exist, then create a fingerprint and create entries in the workflow table for that fingerprint and put the count there.
5. After this determine if the pattern is configured to capture the one-time or lifetime values for the parameters, if set to do so. Then go and update the correct profile table. While doing this, if the profile table does not have an entry for this entity, create the entry. Data1 through Data10 fields from entity profile tables will be used to capture the pattern membership and the values.
6. Repeat Steps a through e for rest of the patterns.
Repeat Steps 1 through 4 for each transaction.

B.2 APIs for Triggering Pattern Data Processing

The APIs for triggering patterning data processing are

updateTransaction
updateAuthStatus
processPatternAnalysis

The updateAuthStatus and updateTransaction APIs are similar to other update authentication and transaction status APIs. The only difference is that updateTransaction, updateAuthStatus, and processPatternAnalysis perform pattern data processing in addition to the updating status of authentication or transaction.

B.2.1 updateTransaction

API to update a previously created transaction.

It also triggers pattern data processing if appropriate. A nonzero value of analyzePatterns will result in triggering the pattern processing if not already performed for this transaction.

public VCryptResponse updateTransaction(
                    Transaction UpdateRequestData transactionUpdateRequest Data);

Table B-1 updateTransaction Parameter and Returned Value

Parameter	Description
TransactionUpdateRequestData	The object to update a transaction; a handle to the transaction to be updated is either the Transaction ID returned by the method createTransaction, or the external Transaction ID passed to the method createTransaction. it throws the exception BharosaException if it fails validation. The structure of this object is as follows: requestId, identifies the user session; required requestTime, the time of the request; can be null; if null, the server uses the current time transactionId ID, the ID returned by a previous call to createTransaction status, the transaction status analyzePatterns, Boolean to indicate if pattern processing should be performed. When the value is passed in as "true," the pattern processing is performed for the transaction if the "resultStatus" value is "success." externalTransactionId, the external Transaction ID that was passed to createTransaction when the transaction was created
VCryptResponse	The response object; make sure to check isSuccess() before obtaining the Transaction ID with the method getTransactionResponse()

Parameter

Description

TransactionUpdateRequestData

The object to update a transaction; a handle to the transaction to be updated is either the Transaction ID returned by the method createTransaction, or the external Transaction ID passed to the method createTransaction. it throws the exception BharosaException if it fails validation.

The structure of this object is as follows:

requestId, identifies the user session; required
requestTime, the time of the request; can be null; if null, the server uses the current time
transactionId ID, the ID returned by a previous call to createTransaction
status, the transaction status
analyzePatterns, Boolean to indicate if pattern processing should be performed. When the value is passed in as "true," the pattern processing is performed for the transaction if the "resultStatus" value is "success."
externalTransactionId, the external Transaction ID that was passed to createTransaction when the transaction was created

VCryptResponse

The response object; make sure to check isSuccess() before obtaining the Transaction ID with the method getTransactionResponse()

B.2.2 updateAuthStatus

API to update the user node log auth status and trigger the pattern data processing if appropriate. A value of true for analyzePatterns and a value of "success" for the resultStatus of the transaction will result in triggering the pattern processing if not already performed for this transaction.

public VCryptResponse updateAuthStatus(java.lang.String requestId, int resultStatus, int clientType, java.lang.String clientVersion, boolean analyzePatterns)
public VCryptResponse updateAuthStatus(java.lang.String requestId, java.util.Date requestTime, int resultStatus, int clientType, java.lang.String clientVersion, boolean analyzePatterns)

Table B-2 updateAuthStatus Parameters

Parameter	Description
requestId	Request ID
requestTime	Time of update
resultStatus	The authentication result. This is the enumeration value of the authentication result.
clientType	This is an enum value defined to identify the client type used for authentication.
clientVersion	Optional parameter to specify the version of the client used
analyzePatterns	Boolean to indicate if pattern processing should be performed. When the value is passed in as "true," the pattern processing is performed for the transaction if the "resultStatus" value is "success."

B.2.3 processPatternAnalysis

API to trigger the processing of data for pattern matching. This call will only trigger the processing of data for pattern matching. The last parameter transactionType can be used by the authentication type user interactions, since authentication (or login) are not first-class transactions.

public VCryptResponse processPatternAnalysis(java.lang.String requestId, long transactionId, int status, java.lang.String transactionType)

Table B-3 processPatternAnalysis

Parameter	Description
requestId	Request ID
transactionId	Transaction ID to be updated.
status	New Status
transactionType	String that indicates the type of transaction. Has to be "auth" for authentication type. For other types it can be "bill_pay, ....",; basically the type name of the transaction.