11 Implementing OTP Anywhere

11.2.1 One Time Password (OTP)

One Time Password (OTP) is used to authenticate an individual based on a single-use alphanumeric credential. The OTP is delivered to the user's configured delivery method. The user then provides the OTP credential as the response to proceed with the operation. The following are major benefits of using out-of-band OTP:

• If the end user's browser/internet is compromised, the authentication can safely take place in another band of communication separate from the browser

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

11.2.2 Oracle User Messaging Service (UMS)

The UMS Server orchestrates message flows between applications and users. OAAM uses UMS to send email, SMS, IM, or voice message to the user.

11.2.3 Challenge Processor

A challenge processor is java code that implements the ChallengeProcessorIntf interface or extends the AbstractChallengeProcessor class. Custom challenge processors can be created to generate a challenge, validate the challenge answer from the user, and check service delivery and availability statuses. By default OAAM has support (or challenge processor implementations) for KBA question challenges and OTP challenges via SMS and email through UMS delivery.

11.2.4 Challenge Type

"Channel" refers to the delivery channel used to send an OTP to the user (Email, SMS, or IM). The challenge type is the channel that OTP is using to challenge the user. A challenge type can be configured for any differences in handling for a challenge that is required. Handling of challenge types could be any specifics for that challenge type, from generating the "secret" used for the challenge to delivering the "secret" to the user and finally validating the users input. For each type of challenge these primary processes (Generation, Sending, and Validating) could require slightly different code.

11.3.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.

11.3.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.

11.5.1 Integrating UMS

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.

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

11.5.2 Enabling OTP Challenge Types

Enable challenge types by setting the appropriate property to true. By setting the property to true, policies will be able to challenge using OTP via the challenge type (email, SMS, IM, or Voice). The user will see the email, SMS, IM, or Voice page in registration flow.

The challenge type enum is used to associate a Challenge Type with the java code needed to perform any work related to that challenge type. The Challenge Type ID (ChallengeEmail) should match a rule action returned by the rules when that challenge type is going to be used.

11.5.3 Enabling Registration and User Preferences

Enable the registration flow and user preferences by setting these properties to true:

11.6.1 Customizing Registration Fields and Validations

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.

Add Mobile Input Registration Field Properties to client_resource.properties

These properties should be added to the resource bundle.

11.6.2 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.

Add Terms and Conditions Definitions to client_resource.properties

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

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.

11.6.3 Customizing Registration Page Messaging

Add registration properties to client_resource.properties.

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

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.

11.6.4 Customizing Challenge Page Messaging

Add challenge type fields to client_resource.properties.

11.6.5 Customizing OTP Message Text

Add OTP message fields to client_resource.properties.

11.6.6 Enabling Opt Out Functionality

This feature is disabled by default. To enable Opt Out for the user, set the property to true.

11.9.1 com.bharosa.uio.manager.user.UserDataManagerIntf

The methods used in customization are:

• public String getUserData(UIOSessionData sessionData, String key);

• public void setUserData(UIOSessionData sessionData, String key, String value);

11.9.2 Default Implementation - com.bharosa.uio.manager.user.DefaultContactInfoManager

The default implementation expands on the interface to break every get and set into two items: UserDataValue and UserDataFlag. The UserDataFlag is used by OAAM to track that a value has been set, or soft reset a value. When rules are used to check if a user is registered for a given item, the UserDataFlag will be checked in the OAAM database. The UserDataValue is the actual data element entered by the user. In the default implementation this is also stored in the OAAM database, but by extending the DefaultContactInfoManager class and overriding the UserDataValue methods (getUserDataValue and setUserDataValue) the data can be stored in an external location if required.

Methods

public class DefaultContactInfoManager implements UserDataManagerIntf {
 
                  public String getUserData(UIOSessionData sessionData, String key){
                    if (getUserDataFlag(sessionData, key)){
                      return getUserDataValue(sessionData, key);
                    }
 
                    return null;
                  }
 
                  public void setUserData(UIOSessionData sessionData, String key, String value){
                    setUserDataValue(sessionData, key, value);
                    setUserDataFlag(sessionData, key, value);
                  }
 
                  protected void setUserDataValue(UIOSessionData sessionData, String key, String value){
                    VCryptAuthUser clientUser = sessionData.getClientAuthUser();
                    if (clientUser != null) {
                      clientUser.setUserData(BharosaConfig.get("oaam.otp.contact.info.prefix", "otpContactInfo_") + key, value);
                    }
                  }
 
                  protected String getUserDataValue(UIOSessionData sessionData, String key) {
                    VCryptAuthUser clientUser = sessionData.getClientAuthUser();
                    if (clientUser != null) {
                      return clientUser.getUserData(BharosaConfig.get("oaam.otp.contact.info.prefix", "otpContactInfo_") + key);
                    }
 
                    return null;
                  }
 
 
                  protected void setUserDataFlag(UIOSessionData sessionData, String key, String value){
                    VCryptAuthUser clientUser = sessionData.getClientAuthUser();
                    if (clientUser != null) {
                      if (StringUtil.isEmpty(value)) {
                        clientUser.setUserData(BharosaConfig.get("oaam.otp.contact.info.flag.prefix", "otpContactInfoFlag_") + key, null);
                      } else {
                        clientUser.setUserData(BharosaConfig.get("oaam.otp.contact.info.flag.prefix", "otpContactInfoFlag_") + key, "true");
                      }
                    }
                  }
 
                  protected boolean getUserDataFlag(UIOSessionData sessionData, String key) {
                    VCryptAuthUser clientUser = sessionData.getClientAuthUser();
                    if (clientUser != null) {
                      return Boolean.valueOf(clientUser.getUserData(BharosaConfig.get("oaam.otp.contact.info.flag.prefix", "otpContactInfoFlag_") + key));
                    }
 
                    return false;
                  }
 
 
                }
        

11.9.3 Custom Implementation Recommendations

Extend the base implementation class DefaultContactInfoManager, and override the "setUserDataValue" and "getUserDataValue" methods to store the data values where appropriate for you implementation.

Leave the default implementation of "setUserDataFlag" and "getUserDataFlag" in place in order for OAAM to properly track which data has been set for the user.

11.9.4 Configuring Properties

OTP Anywhere registration fields are defined by the user defined enum: bharosa.uio.default.userinfo.inputs.enum.

Each element has a "managerClass" property that designates which class will be used to store the registration data.

For example, the default mobile phone element is as follows:

  bharosa.uio.default.userinfo.inputs.enum=Enum for Contact information
        bharosa.uio.default.userinfo.inputs.enum.mobile=0
        bharosa.uio.default.userinfo.inputs.enum.mobile.name=Mobile Phone
        bharosa.uio.default.userinfo.inputs.enum.mobile.description=Mobile Phone
        bharosa.uio.default.userinfo.inputs.enum.mobile.inputname=cellnumber
        bharosa.uio.default.userinfo.inputs.enum.mobile.inputtype=text
        bharosa.uio.default.userinfo.inputs.enum.mobile.maxlength=16
        bharosa.uio.default.userinfo.inputs.enum.mobile.required=true
        bharosa.uio.default.userinfo.inputs.enum.mobile.order=4
        bharosa.uio.default.userinfo.inputs.enum.mobile.enabled=true
        bharosa.uio.default.userinfo.inputs.enum.mobile.regex=\\d{1}\\D?(\\d{3})\\D?\\D?(\\d{3})\\D?(\\d{4})
        bharosa.uio.default.userinfo.inputs.enum.mobile.errorCode=otp.invalid.mobile
        bharosa.uio.default.userinfo.inputs.enum.mobile.managerClass=com.bharosa.uio.manager.user.DefaultContactInfoManager

As shown, the default mobile phone definition uses the DefaultContactInfoManager class to manage the data. If a custom implementation is desired, the value of the managerClass attribute can be updated in OAAM Admin (or through OAAM Extension shared library) to use a custom class.

11.10.1 Additional Registration Field Definitions Examples

Additional registration field definitions are shown below.

11.10.2 Additional Challenge Message Examples

Other examples of challenge message resource bundles are shown below.

11.10.3 Additional Processors Registration Examples

Additional processor registration properties are listed below.