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

Part Number E14568-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Setting Up OTP Anywhere

OTP Anywhere is a secondary risk-based challenge solution consisting of a server generated one time password delivered to an end user via a configured out of band channel. Supported OTP delivery channels include short message service (SMS), email, instant messaging and voice. OTP Anywhere can be used to compliment KBA challenge or instead of KBA. As well both OTP Anywhere and KBA can be used alongside practically any other authentication type required in a deployment. Oracle Adaptive Access Manager also provides a challenge processor framework. This framework can be used to implement custom risk-based challenge solutions combining third party authentication products or services with OAAM real-time risk evaluations.

This chapter focuses on setting up Oracle Adaptive Access Manager to use OTP for secondary, risk-based user challenges. Out of the box, OAAM provides User Messaging Service (UMS) as the delivery method. For other custom methods, refer to the "Developing Custom Challenge Types" chapter of the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.

9.1 Introduction and Concepts

This section introduces you to the concept of One Time Password (OTP) and how it is used in Oracle Adaptive Access Manager.

9.1.1 What is a One Time Password

A one-time password is a randomly generated, single-use authentication credential. OTP is a form of secondary authentication that is used in addition to standard user name and password credentials to strengthen the existing authentication and authorization process, thereby providing additional security for users. When the user is OTP-challenged, a one-time password is generated and delivered to the user through one of the configured channels. The user must retrieve the one-time password and enter it when prompted, before the one-time password expires.

The one-time password may be either numeric or alphanumeric and any configured length and the randomization algorithm is pluggable.

The following are major benefits of using out-of-band OTP:

  • The one time password is delivered to the valid user through one of the configured channels. These can include SMS, IM, email or voice.

  • The user does not require any proprietary hardware or client software of any kind.

9.1.2 About Out-of-Band OTP Delivery

Oracle Adaptive Access Manager 11g contains one time password authentication capabilities that support delivery of the OTP via the following four out-of-band channels:

  • email

  • SMS

  • voice messaging

  • instant messaging

By default, only cell phone registration is displayed on the OTP Registration page.

9.1.3 How Does OTP Work?

During the Registration process in OAAM, the user is asked to register for questions, image, phrase and OTP (email, phone, and so on) if the deployment supports OTP. Once successfully registered, OTP can be used as a secondary authentication to challenge the user.

The administrator can enable the OTP if the deployment supports OTP. The login process begins with entering standard user name and password credentials. During a session, for example, when the user is making a large transaction, if the user is OTP-challenged, the password is delivered to the user through the configured delivery channel. The user retrieves the one-time password, then enters it.

If the correct answer is provided, the user is directed to continue with the operation. If the user answers incorrectly, he is allowed other attempts until he either answers correctly or is locked out of his account after a certain number of failures. By default, the user is allowed three attempts to provide the correct answer.

9.1.4 OTP Failure Counters

The failure counter is incremented when the user supplies an incorrect answer during an OTP-challenge. OTP failures are counted across sessions.

Whether the user is locked out after a number of successive OTP failures or needs to try providing the OTP again depends on the failure counter value, the maximum number for OTP challenges set by the administrator. When the failure counter exceeds this value, the user is "OTP Locked" with no further opportunity for another attempt to answer. If the user is OTP-locked, he can call the Customer Service Representative to become unlocked.

When the correct OTP is provided by the user, the failure counter is reset to 0 and the user is allowed to proceed with the operation.

9.2 Challenge Type

The challenge type is the delivery channel used to send an OTP to the user. For example, policies can challenge using OTP via the challenge type (email, SMS, IM, or Voice).

Table 9-1 OTP Challenge Types

Challenge Type Description

ChallengeEmail

OTP challenge via email

ChallengeSMS

OTP challenge via SMS

ChallengeIM

OTP challenge via instant messaging

ChallengeVoice

OTP challenge via voice


An integrator can create or configure a challenge type to handle a challenge that is required, such as generating the "secret" used for the challenge to delivering the "secret" to the user and finally validating the user's input.

9.3 KBA vs. OTP

Oracle Adaptive Access Manager deployments may choose to use both KBA and OTP or each separately or no challenge mechanisms at all. If both KBA and OTP are being used in a deployment, the security team may choose to use OTP first for high risk situations and then fall back on KBA.

For example, a user logging in from a new IP in a city he often logs in from is relatively low risk on its own, so a KBA challenge is a good option to gain additional verification that this is the valid user. If, however, a user is attempting a funds transfer of more than $1000 using a device and location he has never accessed from previously and the user has never performed a transfer, a stronger measure such as OTP Anywhere would be warranted.

If a customer has both KBA and OTP enabled, the priority is configurable through properties. The default is to OTP challenge first and then KBA challenge for high risk situations.

For information on KBA and OTP Anywhere priority, see Table 11-22, "OAAM Challenge Trigger Combinations".

9.4 Quick Start

The first step in starting to use OTP Anywhere is to enable it using the Properties Editor in OAAM Admin.

This checklist provides you with the basic steps for enabling OTP Anywhere out of the box. Included are links to pertinent documentation and prerequisites.

Table 9-2 Quick Start for Enabling OTP Out of the Box

#
Task Details

1

Enable OTP Anywhere Registration

OTP Challenge is not enabled by default. It has to be enabled by setting the following properties to true:

  • bharosa.uio.default.register.userinfo.enabled

    Setting this property to true enables OTP profile in the registration flow

  • bharosa.uio.default.userpreferences.userinfo.enabled

    Setting this property to true enables the OTP profile in User Preferences

2

Make SMS Challenge Type Available.

Enable the SMS Challenge Type by setting the following property to true:

bharosa.uio.default.challenge.type.enum.ChallengeSMS.available

This makes it possible for the policies to challenge using OTP via SMS.

3

Configure UMS URLs and Credentials.

Set the following properties:

  • bharosa.uio.default.ums.integration.webservice - UMS Web service URL

  • bharosa.uio.default.ums.integration.parlayx.endpoint - UMS ParlayX URL

  • bharosa.uio.default.ums.integration.useParlayX=false - Configures use of Web service or parlayx API. Value is false by default (preferred).

  • bharosa.uio.default.ums.integration.userName - UMS integration user name

  • bharosa.uio.default.ums.integration.password - UMS integration password


9.5 Setting Up OTP Anywhere

This section contains details for advanced set up of OTP Anywhere and discusses the following topics:

9.5.1 Setup Overview

Table 9-3 describes the tasks for customizing OTP usage. The table also provides information on where to get more details about each task.

Table 9-3 Tasks in the OTP Setup

Task Description Documentation

Task 1 - Configure UMS

Enable and configure User Messaging Service (UMS) for SMS delivery gateways on the SOA that the OAAM Server is configured to send messages through and the SMS delivery channel.

UMS comes with a number of drivers that handle traffic for a specific channel. Configure UMS to use SMS for sending the one-time password.

Refer to Configure UMS.

Task 2- Set up UMS URLs and credentials.

Set up UMS URLs and credentials so that OAAM can communicate with the UMS server via web services APIs to send the OTP code to the user via the challenge type.

Refer to Section 9.5.3, "Configuring UMS Server URLs and Credentials."

Task 3 - Enable SMS challenge type.

Enable the SMS challenge type so that it can be used to challenge the user if secondary authentication is required.

Refer to Section 9.5.4, "Enabling and Defining the OTP Challenge."

Task 4 - Make sure out-of-the-box policies are available and active

Make sure out-of-the-box policies are available and active.

Refer to Section 9.5.5, "Configuring Policies and Rules to Use OTP Challenge."

Task 5 - Enable Registration and User Preferences and registration options

Enable registration and user preferences. The user can use the pages for profile registration and resetting OTP profile.

Refer to Section 9.5.6, "Enabling Registration and Preferences."

Task 6 - Set up the registration and preferences page input fields and validations

Set up the registration and preferences page input fields for the user. Input properties includes maximum length for the email address the user can enter, validation for the email address field (expression), and so on.

Note: Any user facing strings need to be duplicated into resource bundle.

Refer to Section 9.5.7, "Customizing Registration Fields and Validations."

Task 7 - Define the properties of the challenge for the OTP

Define the properties of the challenge for the OTP. For example, define the required field for registration and register the challenge processor that is handling the type of processor.

Refer to Section 9.5.10, "Customizing Challenge Page Messaging."

Task 8 - Customize the Message Containing the One Time Password

Customize the Message Containing the One Time Password

Refer to Section 9.5.11, "Customizing OTP Message Text."

Task 9 - Configure OTP presentation

The type of device is defined for the specific type of challenge.

Refer to Section 9.5.12, "Configuring OTP Presentation."


9.5.2 Configure UMS

Ensure that the following prerequisites are met before configuring OTP for your application.

9.5.2.1 Install SOA Suite

Oracle SOA Suite must be installed outside of the OAAM domains. UMS is a part of SOA.

For information, refer to the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

9.5.2.2 Configure the UMS Driver

UMS must be configured for appropriate delivery gateways on the SOA that the OAAM Server is configured to send messages through.

UMS Drivers connect UMS to the messaging gateways, adapting content to the various protocols supported by UMS. Drivers can be deployed or undeployed independently of one another depending on what messaging channels are available in a given installation.

9.5.2.2.1 Email Driver

Configure the Email driver to a SMTP server. See the "Configuring the Email Driver" section of Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite for how to configure the Email driver.

9.5.2.2.2 SMPP Driver

Short Message Peer-to-Peer (SMPP) is one of the most popular GSM SMS protocols. User Messaging Service includes a prebuilt implementation of the SMPP protocol as a driver that is capable of both sending and receiving short messages.

Note:

For SMS, unlike the Email driver that is deployed out-of-the-box, you need to deploy the SMPP driver first before modifying the configurations.

Configure the SMPP driver as described in the "Configuring the SMPP Driver" section of the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite. You will need to provide parameter values for connecting to the driver gateway vendor.

Table 9-4 Connecting to the Vendor

Parameter Description

SmsAccountId

The Account Identifier on the SMS-C. This is your vendor account ID which you need to get from the vendor.

SmsServerHost

The name (or IP address) of the SMS-C server. TransmitterSystemId

TransmitterSystemPassword

The password of the transmitter system. This includes Type of Password (choose from Indirect Password/Create New User, Indirect Password/Use Existing User, and Use Cleartext Password) and Password. This is the password corresponding to your vendor account ID

TransmitterSystemType

The type of transmitter system. The default is Logica.

ReceiverSystemId

The account ID that is used to receive messages. ReceiverSystemPassword

ReceiverSystemType

The type of receiver system. The default is Logica.

ServerTransmitterPort

The TCP port number of the transmitter server.

ServerReceiverPort

The TCP port number of the receiver server.

DefaultEncoding

The default encoding of the SMPP driver. The default is IA5. Choose from the drop-down list: IA5, UCS2, and GSM_DEFAULT.

DefaultSenderAddress

Default sender address


9.5.3 Configuring UMS Server URLs and Credentials

The properties to set for the UMS server URLs and credentials are listed below. They can be edited using the Property Editor in OAAM Admin.

Note: End point is the Web Services URL that OAAM uses to send calls into UMS.

Table 9-5 UMS Server URLs and Credentials

Property Default Value Description

bharosa.uio.default.ums.integration.webservice

 

UMS Server Web service URL

http://<UMS Server URL>:<UMS Port>/ucs/messaging/webservice

bharosa.uio.default.ums.integration.parlayx.endpoint

 

UMS Server ParlayX Endpoint URL

http://<UMS Server URL>:<UMS Port>/sdpmessaging/parlayx/SendMessageService

bharosa.uio.default.ums.integration.useParlayX

false

Configures the use of web service or parlayx API. The value is false by default (Web services recommended)

bharosa.uio.default.ums.integration.userName

 

Username for UMS server

bharosa.uio.default.ums.integration.password

 

Password for UMS server

bharosa.uio.default.ums.integtaion.policies

 

UMS authentication policies

bharosa.uio.default.ums.integration.fromAddress

demo@oracle.com

OAAM from address for OTP messages

bharosa.uio.default.ums.integration.message.status.poll.attempts

3

Number of times to attempt status poll each time the wait page is displayed

bharosa.uio.default.ums.integration.message.status.poll.delay

1000

Delay between status polls while the wait page is being displayed

bharosa.uio.default.ums.integration.sleepInterval

10000

 

bharosa.uio.default.ums.integration.deliveryPage.delay

3000

 

After you set up the UMS server properties, restart the application.

9.5.4 Enabling and Defining the OTP Challenge

The challenge type is the channel that OTP can use to challenge the user, such as Email, SMS, IM, and so on. The challenge type properties are used to associate a Challenge Type with a Challenge Processor, the java code needed to perform any work for challenges.

Enable the OTP challenge type you want to use to challenge the user if secondary authentication is required by setting the available flag. Set bharosa.uio.default.challenge.type.enum.ChallengeSMS.available to true.

Then, you can define the properties for the OTP challenge type, such as the required field for registration, and register the challenge processor that is handling the challenge processing.

To enable and define a challenge type, such as ChallengeEmail, ChallengeSMS, ChallengeQuestion, and so on, perform the following steps:

  1. Log in to OAAM Admin.

  2. In the Navigation tree, double-click Properties under the Environment node. The Properties Search page is displayed.

  3. Search for bharosa.uio.default.challenge.type.enum and edit the properties for the out-of-the-box OTP challenge type:

SMS Challenge Type

The following is an example of an enum defining SMS challenge for OTP:

Table 9-6 Properties for SMS Challenge Type

Property Default Value Description

bharosa.uio.default.challenge.type.enum.ChallengeSMS

2

SMS Challenge enum value

bharosa.uio.default.challenge.type.enum.ChallengeSMS.name

SMS Challenge

Name of SMS challenge type

bharosa.uio.default.challenge.type.enum.ChallengeSMS.description

SMS Challenge

Description of SMS challenge type

bharosa.uio.default.challenge.type.enum.ChallengeSMS.processor

com.bharosa.uio.processor.challenge.ChallengeSMSProcessor

Processor class for SMS challenge type

Specifies the java class for handling challenges of this type. The challenge mechanism is customizable through Java classes. See the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for information.

bharosa.uio.default.challenge.type.enum.ChallengeSMS.requiredInfo

mobile

Required fields to challenge user with SMS challenge type

A comma separated list of inputs from registration input enum

bharosa.uio.default.challenge.type.enum.ChallengeSMS.available

false

Availability flag for SMS challenge type

Specifies if the challenge type is available for use (service ready and configured). To enable/disable an OTP challenge type, the available flag should be set.

bharosa.uio.default.challenge.type.enum.ChallengeSMS.otp

true

OTP flag for SMS challenge type


Email Challenge Type

The following is an example of the enum defining the challenge type, email challenge, for OTP:

Table 9-7 Properties for Email Channel Type

Property Default Value Description

bharosa.uio.default.challenge.type.enum.ChallengeEmail

1

Email Challenge enum value

bharosa.uio.default.challenge.type.enum.ChallengeEmail.name

Email Challenge

Name of email challenge type

bharosa.uio.default.challenge.type.enum.ChallengeEmail.description

Email Challenge

Description of email challenge type

bharosa.uio.default.challenge.type.enum.ChallengeEmail.processor

com.bharosa.uio.processor.challenge.ChallengeEmailProcessor

Processor class for email challenge type

Specifies the java class for handling challenges of this type. The challenge mechanism is customizable through Java classes. See the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for information.

bharosa.uio.default.challenge.type.enum.ChallengeEmail.requiredInfo

email

Required fields to challenge user with email challenge type

A comma separated list of inputs from registration input enum

bharosa.uio.default.challenge.type.enum.ChallengeEmail.available

false

Availability flag for email challenge type

Specifies if the challenge type is available for use (service ready and configured). To enable/disable an OTP challenge type, the available flag should be set.

bharosa.uio.default.challenge.type.enum.ChallengeEmail.otp

true

OTP flag for email challenge type


9.5.5 Configuring Policies and Rules to Use OTP Challenge

Policies in the Challenge checkpoint determine the type of challenge to present the user. For more information, refer to Section 11.5.5.1, "OAAM Challenge."

To configure a policy with a rule that OTP-challenge users for specific scenarios, perform the following steps:

  1. Log in to OAAM Admin.

  2. Create a policy with the Challenge checkpoint.

  3. Add a rule to the policy with the User: Check OTP failures condition.

  4. In the Conditions tab, specify the OTP Challenge Type when you define the condition.

  5. In the Results tab, select the Challenge Type for the Action group.

  6. If you want challenge questions enabled as well, use the Properties Editor and ensure that bharosa.uio.default.challenge.type.enum.ChallengeQuestion.available is set to true.

    In default policies, if OTP is enabled, KBA challenges occurs after a user is OTP blocked.

    High risk user are OTP Challenged. The user is presented with the appropriate virtual authentication device and receives the OTP through the proper channel. If the user fails the OTP challenge, he is KBA-challenged.

  7. Link the policy to all users.

9.5.6 Enabling Registration and Preferences

For the end user to be able to enter his profile and reset phases at a later time, the following properties must be enabled so that the fields that are set up for the pages can be used.

  1. Ensure that the OTP Challenge types are enabled.

  2. Use the Properties Editor in the OAAM Admin to enable OTP profile registration and preference setting. The properties are listed below.

    Table 9-8 Enable OTP Profile Registration and Preference Setting

    Property Description

    bharosa.uio.default.register.userinfo.enabled

    Setting the property to true enables the profile registration pages if the OTP channel is enabled and requires registration.

    bharosa.uio.default.userpreferences.userinfo.enabled

    Setting the property to true enables the user to set preferences if the OTP channel is enabled and allows preference setting.

    User Preferences is a page that allows the user to change their image/phrase, challenge questions, un-register devices, and update their OTP profile.


9.5.7 Customizing Registration Fields and Validations

Set up text and fields on registration and preference pages. Input properties includes maximum length for the email address the user can enter, validation for the email address field (expression), and so on.

If user information registration or user preferences is set to true, the settings are used for the OTP registration and preferences page. The bharosa.uio.default.userinfo.inputs.enum property values are shown in Table 9-9.

Table 9-9 OTP Registration Input Properties

Property Description

inputname

Name used for the input field in the HTML form

inputtype

Set for text or password input

maxlength

Maximum length of user input

required

Set if the field is required on the registration page

order

The order displayed in the user interface

regex

Regular expression used to validate user input for this field

errorCode

Error code used to look up validation error message (bharosa.uio.<application ID>.error.<errorCode>)

managerClass

java class that implements com.bharosa.uio.manager.user.UserDataManagerIntf (if data is to be stored in Oracle Adaptive Access Manager database this property should be set to com.bharosa.uio.manager.user.DefaultContactInfoManager)


Mobile registration field definitions and validations for the OTP registration page are shown below.

Add Mobile Input Registration Field Properties to bharosa_server.properties

These properties should be added to bharosa_server.properties.

Table 9-10 Mobile Input - Properties File

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.mobile

0

Mobile phone enum value

bharosa.uio.default.userinfo.inputs.enum.mobile.name

Mobile Phone

Name for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.description

Mobile Phone

Description for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.inputname

cell number

HTML input name for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.inputtype

text

HTML input type for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.maxlength

15

HTML input max length for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.required

true

Required flag for mobile phone field during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.mobile.order

1

Order on the page for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.enabled

true

Enabled flag for mobile phone enum item

bharosa.uio.default.userinfo.inputs.enum.mobile.regex

\\D?(\\d{3})\\D?\\D?(\\d{3})\\D?(\\d{4})

Regular expression for validation of mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.errorCode

otp.invalid.mobile

Error code to get error message from if validation of mobile phone entry fails

bharosa.uio.default.userinfo.inputs.enum.mobile.managerClass

com.bharosa.uio.manager.user.DefaultContactInfoManager

Java class to use to save / retrieve mobile phone from data storage


Add Mobile Input Registration Field Properties to client_resource.properties

These properties should be added to the resource bundle.

Table 9-11 Mobile Input - Resource Bundle

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.mobile.name

Mobile Phone

Name for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile.description

Mobile Phone

Description for mobile phone field


Other Examples

The following is an example of an enum for adding a second mobile device to register:

Table 9-12 Mobile Input

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.mobile2

2

Mobile phone enum value

bharosa.uio.default.userinfo.inputs.enum.mobile2.name

Mobile Phone 2

Name for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.description

Mobile Phone 2

Description for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.inputname

cell number 2

HTML input name for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.inputtype

text

HTML input type for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.maxlength

15

HTML input max length for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.required

true

Required flag for mobile phone field during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.mobile2.order

2

Order on the page for mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.enabled

true

Enabled flag for mobile phone enum item

bharosa.uio.default.userinfo.inputs.enum.mobile2.regex

\\D?(\\d{3})\\D?\\D?(\\d{3})\\D?(\\d{4})

Regular expression for validation of mobile phone field

bharosa.uio.default.userinfo.inputs.enum.mobile2.errorCode

otp.invalid.mobile

Error code to get error message from if validation of mobile phone entry fails

bharosa.uio.default.userinfo.inputs.enum.mobile2.managerClass

com.bharosa.uio.manager.user.DefaultContactInfoManager

Java class to use to save / retrieve mobile phone from data storage


The following is an example of an enum defining email registration on the OTP registration page of an authenticator:

Table 9-13 Email Input

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.email

1

Email address enum value

bharosa.uio.default.userinfo.inputs.enum.email.name

Email Address

Name for email address field

bharosa.uio.default.userinfo.inputs.enum.email.description

Email Address

Description for email address field

bharosa.uio.default.userinfo.inputs.enum.email.inputname

email

HTML input name for email address field

bharosa.uio.default.userinfo.inputs.enum.email.inputtype

text

HTML input type for email address field

bharosa.uio.default.userinfo.inputs.enum.email.maxlength

40

HTML input max length for email address field

bharosa.uio.default.userinfo.inputs.enum.email.required

true

Required flag for email address field during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.email.order

2

Order on the page for email address field

bharosa.uio.default.userinfo.inputs.enum.email.enabled

false

Enabled flag for email address enum item

bharosa.uio.default.userinfo.inputs.enum.email.regex

.+@[a-zA-Z_]+?\\.[a-zA-Z]{2,3}

Regular expression for validation of email address field

bharosa.uio.default.userinfo.inputs.enum.email.errorCode

otp.invalid.email

Error code to get error message from if validation of email address entry fails

bharosa.uio.default.userinfo.inputs.enum.email.managerClass

com.bharosa.uio.manager.user.DefaultContactInfoManager

Java class to use to save / retrieve email address from data storage


The following is an example of an enum for adding a second email to register:

Table 9-14 Email Input

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.email2

2

Email address enum value

bharosa.uio.default.userinfo.inputs.enum.email2.name

Email Address 2

Name for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.description

Email Address 2

Description for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.inputname

email2

HTML input name for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.inputtype

text

HTML input type for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.maxlength

40

HTML input max length for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.required

true

Required flag for email address field during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.email2.order

2

Order on the page for email address field

bharosa.uio.default.userinfo.inputs.enum.email2.enabled

false

Enabled flag for email address enum item

bharosa.uio.default.userinfo.inputs.enum.email2.regex

.+@[a-zA-Z_]+?\\.[a-zA-Z]{2,3}

Regular expression for validation of email address field

bharosa.uio.default.userinfo.inputs.enum.email2.errorCode

otp.invalid.email

Error code to get error message from if validation of email address entry fails

bharosa.uio.default.userinfo.inputs.enum.email2.managerClass

com.bharosa.uio.manager.user.DefaultContactInfoManager

Java class to use to save / retrieve email address from data storage


9.5.8 Customizing Terms and Conditions

The following examples show term and conditions definitions for the OTP registration page.

Add Terms and Conditions Definitions to bharosa_server.properties

These properties should be added to bharosa_server.properties.

Table 9-15 Terms and Conditions Checkbox

Property Default Value Description

bharosa.uio.default.userinfo.inputs.enum.terms

4

Terms and Conditions enum value

bharosa.uio.default.userinfo.inputs.enum.terms.name

Terms and Conditions

Name for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.description

Terms and Conditions

Description for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.inputname

terms

HTML input name for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.inputtype

checkbox

HTML input type for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.values

true

Required values for Term and Conditions checkbox during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.terms.maxlength

40

HTML input max length for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.required

true

Required flag for Term and Conditions checkbox during registration and user preferences

bharosa.uio.default.userinfo.inputs.enum.terms.order

5

Order on the page for Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.enabled

true

Enabled flag for Terms and Conditions enum item

bharosa.uio.default.userinfo.inputs.enum.terms.regex

.+

Regular expression for validation of Terms and Conditions checkbox

bharosa.uio.default.userinfo.inputs.enum.terms.errorCode

otp.invalid.terms

Error code to get error message from if validation of Terms and Conditions fails

bharosa.uio.default.userinfo.inputs.enum.terms.managerClass

com.bharosa.uio.manager.user.DefaultContactInfoManager

Java class to use to save / retrieve Terms and Conditions from data storage


Add Terms and Conditions Definitions to client_resource.properties

Default messaging for Terms and Conditions is defined by these resource bundle values:

Table 9-16 Messaging of Terms and Conditions

Property Descriptions

bharosa.uio.default.userinfo.inputs.enum.terms.name

I agree to the [ENTER COMPANY OR SERVICE NAME HERE] terms & conditions. Click to view full <a href="javascript:infoWindow('terms');">Terms & Conditions</a> and <a href="javascript:infoWindow('privacy');">Privacy Policy</a>.

bharosa.uio.default.userinfo.inputs.enum.terms.description

Message and Data Rates May Apply. <br/>For help or information on this program send "HELP" to [ENTER SHORT/LONG CODE HERE]. <br/>To cancel your plan, send "STOP" to [ENTER SHORT/LONG CODE HERE] at anytime.<br/><br/>For additional information on this service please go to <a href="" target="_blank">[ENTER INFORMATIONAL URL HERE]</a>.<br/><br/><b>Supported Carriers:</b><br/>AT&T, Sprint, Nextel, Boost, Verizon Wireless, U.S. Cellular&reg;, T-Mobile&reg;, Cellular One Dobson, Cincinnati Bell, Alltel, Virgin Mobile USA, Cellular South, Unicel, Centennial and Ntelos


The value for bharosa.uio.default.userinfo.inputs.enum.terms.name includes placeholder links that use OAAM Server popup messaging for "Terms & Conditions" and "Privacy Policy". The property and resource keys for the contents of the pop-ups are listed as follows.

Table 9-17 Terms & Conditions and Privacy Policy Popup Messaging

Property Descriptions

bharosa.uio.default.messages.enum.terms.name

Terms and Conditions

bharosa.uio.default.messages.enum.terms.description

PLACEHOLDER TEXT FOR TERMS AND CONDITIONS

bharosa.uio.default.messages.enum.privacy.name

Privacy Policy

bharosa.uio.default.messages.enum.privacy.description

PLACEHOLDER TEXT FOR PRIVACY POLICY


9.5.9 Customizing Registration Page Messaging

Add registration properties to client_resource.properties.

Table 9-18 Registration Resource Bundle

Property Default Value

bharosa.uio.default.register.userinfo.title

OTP Anywhere Registration

bharosa.uio.default.register.userinfo.message

For your protection please enter your mobile telephone number so we may use it to verify your identity in the future. Please ensure that you have text messaging enabled on your phone.

bharosa.uio.default.register.userinfo.registerdevice.message

Check to register the device that you are currently using as a safe device:

bharosa.uio.default.register.userinfo.continue.button

Continue

bharosa.uio.default.register.userinfo.decline.message

If you decline you will not be asked to register again.

bharosa.uio.default.register.userinfo.decline.button

Decline


Decline Button

To control the presence of the Decline button on the profile registration pages, set the following properties:

bharosa.uio.default.register.userinfo.decline.enabled = true

bharosa.uio.default.userpreferences.userinfo.decline.enabled = true

Note:

Even if these are true, the button will not show if the Opt Out property is false.

When the Decline button is enabled, the user will have another option on the OTP registration page that will allow him to Opt out of OTP challenges. He will not be asked to register OTP again, and will not receive OTP challenges. However, if a Customer Care OTP Profile reset is performed (or reset all) the user will have the opportunity to register OTP again.

Also, even if the user has opted out of OTP, he can access the OTP page in User Preferences and add information and click Continue. This will remove the OTP out flag and the user will now be registered for OTP.

9.5.10 Customizing Challenge Page Messaging

Add challenge type fields to client_resource.properties.

Table 9-19 Challenge Type Resource Bundle Items

Property Default Value

bharosa.uio.default.ChallengeSMS.message

For your protection please enter the code we just sent to your mobile telephone. If you did not receive a code please ensure that text messaging is enabled on your phone and click the resend link below.

bharosa.uio.default.ChallengeSMS.registerdevice.message

Check to register the device that you are currently using as a safe device:

bharosa.uio.default.ChallengeSMS.continue.button

Continue


9.5.11 Customizing OTP Message Text

Add OTP message fields to client_resource.properties.

Note:

User facing strings need to be duplicated into resource bundle. Resource bundle values can be customized by adding them to the client_resource_<locale>.properties and deploying the file in OAAM Extensions Shared Library.

Table 9-20 Challenge Type Resource Bundle Items

Property Default Value

bharosa.uio.default.ChallengeSMS.incorrect.message

Incorrect OTP. Please try again.

bharosa.uio.default.ChallengeSMS.message.subject

Oracle OTP Code

bharosa.uio.default.ChallengeSMS.message.body

Your Oracle SMS OTP Code is: {0}


9.5.12 Configuring OTP Presentation

By default, challenge devices are configured through rules. The rules are under the Authentipad checkpoint and determine the type of device to use based on the purpose of the device (ChallengeEmail, ChallengeSMS, ChallengeQuestion, and so on).

To change the OTP Device used for challenges, change the OTP challenge type for the rule's result action.

Alternatively, if you want to configure challenge devices using properties you can bypass the Authentication Pad checkpoint by following these instructions:

  1. Log in to OAAM Admin.

  2. In the Navigation tree, double-click Properties under the Environment node. The Properties Search page is displayed.

  3. Set bharosa.uio.default.use.authentipad.checkpoint to false.

  4. Edit bharosa.uio.default.<ChallengeType>.authenticator.device=<Device> with the challenge type and the property for the desired device.

    bharosa.uio.default.ChallengeSMS.authenticator.device=DeviceTextPad
    bharosa.uio.default.ChallengeEmail.authenticator.device=DeviceTextPad
    

    Table 9-21 shows the property and the authentication pad that would be used. In the above example, the SMS authenticator is the Text Pad since the property, DeviceTextPad, was specified. (DeviceKeyPadAlpha would display a alphanumeric Keypad.)

For authentication device types, refer to Table 9-21.

Table 9-21 Authentication Device Type

Property Description

None

No HTML page or authentication pad

DeviceKeyPadFull

Challenge user using KeyPad.

DeviceKeyPadAlpha

Challenge user with the alphanumeric KeyPad (numbers and letters only, no special characters)

DeviceTextPad

Challenge user using TextPad.

DeviceQuestionPad

Challenge user using QuestionPad.

DevicePinPad

Challenge user using PinPad.

DeviceHTMLControl

Challenge user using HTML page instead of an authentication pad.


The OTP device is displayed at the next login to the application.

9.5.13 Customize Failure Counter

When a user fails the OTP challenge, a counter is updated to indicate that user has had a failure. The failure counter looks across sessions.

The failure counter is set by default in the OAAM Challenge Policy, but you can customize it by following these instructions:

  1. Open the OAAM Challenge Policy.

  2. Open the appropriate maximum failed OTP rule.

  3. In the Conditions tab, select User: Check OTP failures.

  4. Edit the appropriate properties.

    Table 9-22 User: Check OTP failures Values

    Property Description

    Description

    Checks if user's OTP failure counter value is over a specified value.

    Failures more than or equal to

    The number of failed attempts allowed

    If above or equal, return

    True or False

    OTP Challenge Type

    The challenge type is the channel that OTP is using to challenge the user.


9.6 Use Cases

A set of related OTP use cases are provided in this section.

9.6.1 User Case 1: UMS / OTP Configuration

To configure properties for SMS OTP registration and delivery:

  1. Log in to OAAM Admin with environment administrator privileges.

  2. Set the following properties:

    bharosa.uio.default.register.userinfo.enabled = true

    bharosa.uio.default.userpreferences.userinfo.enabled = true

    bharosa.uio.default.ums.integration.webservice=http://<UMS Server URL>:<UMS Port>/ucs/messaging/webservice

    bharosa.uio.default.ums.integration.username = <User name for UMS server>

    bharosa.uio.default.ums.integration.password = <Password for UMS server>

    bharosa.uio.default.challenge.type.enum.ChallengeSMS.available = true

9.6.2 Use Case 2: Always Challenge by Group

If a group of users should be considered high risk every time they log in (regardless of other factors), a policy can be configured to always challenge the group of users with OTP (High Risk).

Administrator

  1. Log in to OAAM Admin.

  2. Create a "High Risk Users" group and add high risk users to the group.

  3. Create an Action group "High Risk User" with the following values:

    Alert type: Fraud

    Alert level: High

    Alert message: High risk user login attempt

  4. Create a policy with the following values:

    Policy Name: OAAM OTP RR

    Policy Status: Active

    Checkpoint: Post-Authentication

    Scoring Engine: Average

    Weight: 100

    Description: OAAM OTP Release Readiness Policy

  5. Add a rule with the following general values:

    Rule Name: In High Risk Group

    Rule Status: Active

    Rule Notes: Checks if user is in high risk user group.

  6. Specify the results for if the rule triggers:

    Score: 1000

    Weight: 100

    Action Group: OAAM Challenge

    Alert Group: High Risk User

  7. Add the condition "USER: User in Login Group" with the following values:

    Is in group: True

    User Group: High Risk Users

User

Note:

User with user name "Henry" has already logged in once and completed registration.

"Henry" logs in to OAAM Server again. He is always challenged with SMS.

9.6.3 Use Case 3: CSR OTP Profile Reset with High Risk Always Challenge by Group

A high risk login from a user, who is registered for KBA but has had his OTP profile reset by customer service, is challenged by other methods before he is allowed to register a new OTP profile.

Note:

The user "Henry" has had his OTP reset.
  1. The user logs in to OAAM Server with the user name "Henry."

    He is challenged with KBA (since OTP is not registered).

  2. He answers the challenge question.

  3. He completes OTP Registration

  4. Later, he logs in again with user name "Henry."

  5. He is OTP Challenged.

9.6.4 Use Case 4: Unregistered Low Risk User (Risk Score 500 or Below)

An unregistered user in a low or no risk login situation is asked to register his image/phrase, challenge questions, and OTP profile.

  1. The user logs in to OAAM Server with user name "Stanley." "Stanley" is a low risk user.

    He is presented with the registration screens.

  2. He completes user registration.

9.6.5 Use Case 5: Registered Low Risk User (Risk Score 500 or Below)

A registered user logging in with a low risk situation is challenged with KBA.

  1. "Frank" logs in to OAAM Server at 1:00 pm.

  2. He does not have to register, so he presses Skip on the Registration page.

  3. "Phil" logs in to OAAM Server with the same device as "Frank" at 2:00 pm.

  4. He does not have to register, so he presses Skip on the Registration page.

  5. "Stanley" logs in to OAAM Server with the same device at 3:00 pm.

  6. "Stanley" is challenged because four users are logging in from the same device within 8 hours. The risk score is 500 (Rule Score is 1000, Weight is 100, Scoring Engine is Average), causing a KBA challenge.

9.6.6 Use Case 6: Unregistered High Risk User (Risk Score Above 500)

A high risk login by an unregistered user is not be permitted to register.

  1. High risk user, "Henry," logs in to OAAM Server with an invalid password four times.

  2. High risk user, "Henry," logs in to OAAM Server with the correct password.

  3. The user is locked since the risk score is 600 because of the invalid login attempts and the user is not registered.

9.6.7 Use Case 7: Registered High Risk User (Risk Score Above 500)

A registered user logs in under a high risk situation and an OTP challenge to occur.

  1. "Stanley" logs in to OAAM Server with the correct password.

  2. He is OTP (SMS) challenged since his risk score is up to 600 because of the invalid login attempts.

9.6.8 Use Case 8: Register High Risk Lockout

A user who has failed too many challenges can have their failure attempts reset by customer service.

In this scenario, a user is locked out by failing to correctly answer a challenge. The CSR must unlock the user, allowing him to log in. The user logs in and is challenged again.

  1. "Stanley" logs in to OAAM Server with the correct password

  2. He is OTP (SMS) challenged and types in an incorrect challenge value three times.

  3. He is asked to answer KBA challenge.

  4. He incorrectly answers KBA three times.

  5. He is blocked.

  6. He attempts to log in again but remains blocked.

  7. The CSR who has logged in to OAAM Admin with CSR privileges, creates a case for "Stanley."

  8. She unlocks OTP for him.

  9. "Stanley" logs in to OAAM Server with the correct password.

  10. He is challenged via OTP.

9.6.9 Use Case 9: High Risk Exclusion

If a user is unable to use OTP, he can be added to an exclusion group to prevent the high risk challenge from occurring.

  1. The Security Administrator logs in to OAAM Admin.

  2. He adds "Stanley" to the "High Risk Exclusion" user group.

  3. He modifies the OAAM Challenge Policy "Check for High Risk Score" rule to use "High Risk Exclusion" as the Excluded User Group in Pre-Conditions.

  4. "Stanley" logs in to OAAM Server.

  5. He is KBA challenged instead of OTP challenged even though he has a high risk score.

9.6.10 Use Case 10: OTP Challenge with Multi-Bucket Patterns

"User: IP" is a multi-bucket pattern that creates a bucket for each IP used by a user. It enables evaluations such as the following: if Jen falls into an IP bucket that is less than 30% of all application users falling into that bucket, then OTP challenge her.

  1. The Security Administrator logs in to OAAM Admin.

  2. He creates a multi-bucket pattern for the member type "user" with an operator, "For each" and attribute "IP."

  3. He confirms a policy which contains a rule with the following conditions- Has this user logged in at least twice in the last 3 months, Compare User Entity with all entities in picture (30%), and Has this user OTP registered.

  4. Jen logs in the OAM Server

  5. She performs OTP registration

  6. She logs in 2 more times from the same IP.

  7. For her 4th login, she logs in from a different IP.

  8. The rule triggers.

  9. At a different IP, she logs in again.

  10. The rule triggers again.