Risk Analytics SDK Overview
This topic provides information about how to use RA Java classes and methods to enable your online application to programmatically perform risk evaluation and related tasks. It describes the Java implementation of the RA SDK. This topic introduces you to the Java APIs provided by RA. It covers the following sub-topics:
cara
This topic provides information about how to use RA Java classes and methods to enable your online application to programmatically perform risk evaluation and related tasks. It describes the Java implementation of the RA SDK. This topic introduces you to the Java APIs provided by RA. It covers the following sub-topics:
2
Introduction to the Risk Analytics SDK
The RA software development kit (SDK) provides a programmatic front-end to RA. It provides APIs for interacting with Transaction Server to perform the tasks needed for assessing each transaction (Risk Evaluation APIs).
After you install RA, the Java SDKs are available at the following location:
Microsoft Windows:
<install_location>\Arcot Systems\sdk\java\lib\arcot\
UNIX-Based Platforms:
<install_location>/arcot/sdk/java/lib/arcot/
If you have not installed RA yet, you can still access these Javadocs in the Documentation directory of the RA package you receive.
Risk Evaluation API
The Risk Evaluation API (arcot-riskfort-evaluaterisk.jar) is the interface to Transaction Server, which provides the logic for evaluating risk associated with a transaction and returning an appropriate advice.
Based on the various factors collected from user’s system and the result of configured rules that are triggered, this API returns a score and a corresponding advice. If RA recommends additional authentication (which is performed by your application), then this API also returns a final advice based on the feedback of this secondary authentication received from your application.
During risk evaluation, a DeviceID is passed to the API, which is then used by Transaction Server to form a user-device association in the database. Based on the end-user’s preferences, this DeviceID is then stored at the client-end either as a browser cookie or an HTML5 localStorage.
This
association
(or device binding) helps identify the risk for transactions originating from a system used by the user for a transaction. Users who are not bound are more likely to be challenged in order to be authenticated. You can also list and delete these associations by using this API.Users can be bound to more than one device (for example, someone using a work and home computer) and a single device can be bound to more than one user (for example, a family sharing a computer).
Risk Analytics SDK Features
This section discusses the salient features of the Risk Evaluation SDK.
- Multiple Ways to Initialize the SDKsYou can initialize Risk Evaluation SDK either by using properties file or by using a map. See Before You Begin Using the Risk Analytics SDK for more information about how to do this.
- Support for SDK FailoverJava SDKs support failover mechanism. If an instance of Transaction Server is not operational, then the SDKs automatically connect to any of the additional configured instances. See Performing Additional SDK Configurations for information about configuring a backup Transaction Server instance.
- Support for SSLYou can secure the connection between the Java SDK and Transaction Server by using Secure Sockets Layer (SSL). To set up SSL between SDK and Transaction Server, you must edit the RA properties files. See Performing Additional SDK Configurations for more information about SSL configurations.
- Support for Additional ParametersIn addition to the mandatory inputs, the APIs also accept additional input that can be passed as name-value pair. This input can include information, such as locale, calling application details, or additional transaction details.
Overview of the Integration Steps
The RA SDK offers you multiple degrees of freedom in the available integration methods and the types of risk-based authentication flows. (See Risk Analytics SDK Use Cases for more information about supported workflows.) This enables you to design the optimal authentication solution that best suits your organization’s requirements.
The RA flows can be integrated with your online application at the points discussed in following subsections.
Before a User Logs in to Your Application (and Just Accesses the Login Page)
In this case, your application must invoke RA’s evaluateRisk() function call from the login page (
before
the user specifies the login credentials) to assess the risk associated with the incoming data. For example, you can evaluate the IP address and/or the country for Negative IP and Negative Country checks.Negative IP addresses is a collection of IP addresses that have been the origin of known anonymizer proxies or fraudulent or malicious transactions in the past. Similarly, Negative countries is a collection of all countries from which fraudulent or malicious transactions have been recorded in the past.
In this case, you can also evaluate other RA rules that do not require user information. These include Device Velocity Check and any custom rules you might have implemented.
After a User Logs in to Your Online Application (By Specifying the User Name and Password to Access Their Account or the Protected Resource)
In this case:
- Your application must invoke RA from the main page of your application that appears after successful login. The following scenarios are possible:
- User is enrolled with RA, and must undergo risk evaluation.In this case, your application must invoke RA’s evaluateRisk() function call by passing user, device signature (collected by using the DeviceDNA Javascript provided by RA), IP address, and transaction details for assessing the risk:
- If the received user data is assigned a low score after rule execution (based on the incoming data and the data stored for this user or device), then the advice is ALLOW. In this case, your application grants access to the user to the protected resource or Web page and allows the user to continue with the transaction.
- If the received user data is assigned a high score after rule execution (based on the incoming data and the data stored for this user or device), then the advice is DENY. In this case, your organizational policies determine the outcome. The transaction can be denied or can be forwarded to a security analyst (known as Customer Support Representative (CSR) in RA terminology) for review and further action.
- If a transaction is flagged as suspicious, then the advice is INCREASEAUTH. In this case, your application must perform a secondary authentication, which can include industry-standard one-time password (OTP) or security questions (such as mother’s maiden name and date of birth).
You can also use CA AuthMinder for this purpose.See http://www.ca.com/us/two-factor-authentication.aspx for more information. - User is new to RA, and therefore must be enrolled with it.In this case, your application must invoke RA’s createUserRequest message in the ArcotUserManagementSvc Web service by passing user details to create the user in RA database.Because RA works "behind the scene" for an end user, you must not change the end-user experience for this enrollment.After RA "knows" the user after this enrollment, then you must call the evaluateRisk() function and allow the user to proceed with the transaction, if the advice is ALLOW.See the enrollment workflows in Risk Analytics SDK Use Cases for the two different ways in which you can enroll users.
- Your application invokes RA’s postEvaluate() function after the evaluateRisk() function. Transaction Server determines whether to create a user-device association and update the attributes based on the results of this function.