Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager
11g Release 2 (11.1.2.0)

Part Number E27207-20
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

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

18 Modeling the Transaction in OAAM

In order for Oracle Adaptive Access Manager to perform analysis on transactions, you must determine how to represent the transactions in Oracle Adaptive Access Manager, how to process the data coming in, how to use the data, and how to display the data. For example, in an ecommerce transaction, the data involved are credit card numbers, shipping and billing addresses, names, dollar amounts and so on; for a wire transfer, the data involved are Amount, Name, To account, From account, Routing Number, Bank Address, Bank Phone, and so on.

This chapter describes how to use entity and transaction definitions in OAAM.

18.1 Introduction

Determining which items in a transaction are entities and creating the entities saves time, improves performance in the system, decreases the amount of data created, and enables rules using the entity to run faster than if they had used transactional data.

An entity can be used and reused in multiple places, which makes creating transaction definitions much easier. An example of an entity that can be reused is an address. A shipping address and billing address can be created for different transactions from the address entity. If you had defined address as transactional data, you would have to define it twice.

18.2 Use Case

The use case may be to notify the security administrator if a customer is trying to make a purchase and his billing and shipping addresses (street, city, state, and zipcode) are different. A mismatch may indicate that the customer is sending the item to an address different from the address the bill is sent to. A mismatch may mean that a fraudster is using a stolen credit card to buy the item, but there might be valid reasons like the customer might want his purchase sent to his work or he may be purchasing a gift for someone who lives at a different address.

18.3 Set Up the Use Case

To set up this use case:

  1. Develop the security policy that will accomplish the use case.

    1. Determine what you are trying to accomplish (problem statement).

    2. Break the problem statement into:

      Inputs: What data is available to evaluate?

      Rules: What types of evaluations do I need to perform on the data?

      Outcomes: What should happen based on the analysis?

    3. Translate the wording of the problem statement into a security policy by mapping the data, evaluations, and outcomes to an OAAM configuration.

18.4 Determine How to Model the Transaction in OAAM in Terms of OAAM Entities and Transactions

An outline for determining how to model the transaction is as follows:

  1. After receiving the source data from the customer, identify the mapping between the source data and OAAM entities and transaction. Source data elements are the fields from the customer application.

    Table 18-1 Data Fields and Source Keys

    Data Name Internal ID of Source Fields

    Item

    itemId

    Price

    itemPrice

    Count

    itemCount

    First Name

    customer.firstName

    Last Name

    customer.lastName

    Credit Card

    creditCard.number

    CC Expiration Date

    creditCard.expDate

    CC Issuing Country

    creditCard.issuingCountry

    Is Shipping Address Same?

    shippingAddress.addressSame

    Address Line1

    shippingAddress.addressLine1

    Address Line2

    shippingAddress.addressLine2

    Address Line3

    shippingAddress.addressLine3

    City

    shippingAddress.city

    State

    shippingAddress.state

    Country

    shippingAddress.country

    Pin Code

    shippingAddress.pinCode

    Address Line1

    billingAddress.addressLine1

    Address Line2

    billingAddress.addressLine2

    Address Line1

    billingAddress.addressLine3

    City

    billingAddress.city

    State

    billingAddress.state

    Country

    billingAddress.country

    Pin Code

    billingAddress.pinCode


  2. Use the OAAM Administration Console to create and activate the entities and transaction definitions for the transaction based on the model you came up with.

18.5 After Creating Entities and Transaction Definitions

The following steps occur after entities and transaction creation.

  1. Determine the OAAM checkpoint that can be used to trigger the fraud policies that can perform fraud checks on the transaction. If an existing checkpoint can be reused, there is no need to create a checkpoint. Otherwise, create an OAAM checkpoint for the transaction.

  2. Now, look at the requirements for what kind of rules should go into the fraud policy for this transaction.

  3. Look at the list of transaction rule conditions to see which rule condition is needed. Go through the "Example Usage" section of those rule conditions.

  4. Create an OAAM policy and add the rule.

  5. Once the rule condition is configured, specify what should be the Results if the rule condition is satisfied. You can configure Alert and Action groups that indicate that the user has reached his threshold and also a score. The client application can interpret the result and take appropriate action in terms of redirecting the user to the relevant pages that indicate that the user action is not allowed.

  6. Now, you have the setup ready in OAAM so that the transaction can be created in OAAM and fraud policies and rules can be triggered.

  7. Integrate the client application with OAAM using OAAM shared libraries. Refer to "Integrating Native Java Applications" in the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for details of the integration. This is required since transactions functionality is available through native integration. As part of this integration, the client application does two things:

    • Call the OAAM Data Collection API to pass the transaction data. OAAM Data Collection APIs persist the transaction data based on the transaction definition into the OAAM database. This results in the creation of OAAM entities and transaction data. The output of these APIs is a Transaction ID.

    • Call the OAAM Rules API to trigger the fraud policies/rules associated to the checkpoint. This step results in triggering the rules engine that would execute the policies and rules associated to this checkpoint and creating Alerts if the associated rules trigger. The output of these APIs is a set of actions and risk score as returned by the policies and rules.

  8. Once the integration with client application is done, you can perform a sample transaction and verify the end-to-end flow.

18.6 Healthcare Domain Deployment

A healthcare organization that cannot provide secure access to its data will suffer significant damage to their institution's reputation, the loss of trust by patients, stakeholders, and the community, and suffer severe penalties. Maintaining secure data is a process that affects all healthcare facility employees, including IT and all partners, insurers, and vendors that work with the provider. OAAM has a set of fraud auditing and detection tools, which can be used to assist organizations. During the discovery phase in a healthcare domain deployment, the business analyst identifies user activities that need to be monitored. User activities could be read-only access of sensitive data such as patient information or actions to add or manage data. Some examples of user activities are:

For these use cases, entity-attribute information must be mapped out and a policy must be developed for "Patient Record Access". During the design phase, Entities, Transactions, Rules, Policies, Alerts and Configurable actions are defined.

Unusually High Frequency of Access by Employee to Patient Records

Description: Frequency of employee's access to patient records increases to unusually high frequency.

Conditions:

IF employee has accessed patient records during each of the last 12 months

AND Employee has accessed > 500% more patient records in the last six months than in the previous six months

THEN report on potential inappropriate patient record access.

Parameters

Required data:

Reported As

"Employee [Person ID, Name,] accessed > 500% more patient records in the last six months than in the previous six months."