WorkflowsProcesses Guide

RSA Adaptive Authentication
(On-Premise) 7.1
Workflows and Processes Guide
Contact Information
Go to the RSA corporate website for regional Customer Support telephone and fax numbers:
www.emc.com/domains/rsa/index.htm
Trademarks
RSA, the RSA Logo, and EMC are either registered trademarks or trademarks of EMC Corporation in the United States
and/or other countries. All other trademarks used herein are the property of their respective owners. For a list of EMC
trademarks, go to www.emc.com/legal/emc-corporation-trademarks.htm#rsa.
License Agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and
may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice
below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any
other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Note on Encryption Technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this
product.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE
Copyright 2013 EMC Corporation. All Rights Reserved. Published in the USA.
July 2013
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide
Preface
About This Guide

This guide introduces the recommended workflows for RSA Adaptive
Authentication (On-Premise) 7.1. This guide is intended for system administrators,
security analysts, and other trusted personnel. Do not make this guide available to the
general user population.
RSA Adaptive Authentication (On-Premise) Documentation

For more information about RSA Adaptive Authentication (On-Premise), see the
following documentation:
Authentication Plug-In Developers Guide. Describes the Authentication Plug-In
development process that enables external authentication providers to integrate
their products with RSA Adaptive Authentication (On-Premise).
Back Office Users Guide. Provides an overview of the following Back Office
applications: Policy Management, Case Management, Access Management,
Customer Service Administration, and the Report Viewer.
Bait Credentials Setup and Implementation Guide. Describes how to set up and
implement RSA bait credentials, which help provide you with accelerated fraud
detection and prevention capabilities.
Best Practices for Challenge Questions. Describes the best practices related to
challenge questions that RSA has evolved through experience at multiple
deployments.
Installation and Upgrade Guide. Describes detailed procedures on how to install,
upgrade, and configure RSA Adaptive Authentication (On-Premise).
Integration Guide. Describes how to integrate and deploy
RSA Adaptive Authentication (On-Premise).
Operations Guide. Provides information on how to administer and operate
RSA Adaptive Authentication (On-Premise) after upgrade. This guide also
describes how to configure Adaptive Authentication (On-Premise) within the
Configuration Framework.
Performance Guide. Provides information about performance testing and
performance test results for the current release version of Adaptive Authentication
(On-Premise).
Product Overview Guide. Provides a high-level overview of RSA Adaptive
Authentication (On-Premise), including system architecture.
Preface 3
Release Notes. Provides information about what is new and changed in this
release, as well as workarounds for known issues. It also includes the supported
platforms and work environments for platform certifications. The latest version of
the Release Notes is available on RSA SecurCare Online at
https://knowledge.rsasecurity.com.
Security Best Practices Guide. Provides recommendations for configuring your
network and RSA Adaptive Authentication (On-Premise) securely.
Web Services API Reference Guide. Describes RSA Adaptive Authentication
(On-Premise) web services API methods and parameters. This guide also
describes how to build your own web services clients and applications using web
services API to integrate and utilize the capabilities of Adaptive Authentication
(On-Premise).
Whats New. Highlights new features and enhancements in
RSA Adaptive Authentication (On-Premise) 7.1.
Workflows and Processes Guide. Describes the workflows and processes that
allow end users to interact with your system and that allow your system to interact
with RSA Adaptive Authentication (On-Premise).
Support and Service

RSA SecurCare Online https://knowledge.rsasecurity.com
Customer Support Information www.emc.com/support/rsa/index.htm
RSA Solution Gallery https://gallery.emc.com/community/marketplace/rsa?

view=overview
RSA SecurCare Online offers a knowledgebase that contains answers to common

questions and solutions to known problems. It also offers information on new releases,
important technical news, and software downloads.
The RSA Solution Gallery provides information about third-party hardware and
software products that have been certified to work with RSA products. The gallery
includes Secured by RSA Implementation Guides with step-by-step instructions and
other information about interoperation of RSA products with these third-party
products.
Before You Call Customer Support

Make sure that you have direct access to the computer running the RSA Adaptive
Authentication (On-Premise) software.
Please have the following information available when you call:
Your RSA Customer/License ID.
RSA Adaptive Authentication (On-Premise) software version number.
The make and model of the machine on which the problem occurs.
The name and version of the operating system under which the problem occurs.
4 Preface
Contents
Preface................................................................................................................................... 3
About This Guide................................................................................................................ 3
RSA Adaptive Authentication (On-Premise) Documentation.......................................... 3
Support and Service ............................................................................................................ 4
Before You Call Customer Support............................................................................. 4
Chapter 1: Understanding the Workflows ....................................................... 9

Types of Workflows............................................................................................................ 9
Main Workflows .......................................................................................................... 9
Dependent Workflows ............................................................................................... 10
Customer Service Workflows .....................................................................................11
Sign in Types .....................................................................................................................11
Transaction Behaviors....................................................................................................... 12
Chapter 2: Authentication Workflow ................................................................ 13

Chapter 3: Logon Monitoring Workflow ......................................................... 17
Best Practices for Logon Monitoring................................................................................ 18
Chapter 4: Transaction Authentication Workflow .................................... 19

Best Practices for Transaction Authentication.................................................................. 21
Chapter 5: Enrollment Workflow ......................................................................... 23

Chapter 6: Transaction Monitoring Workflow............................................. 27
Chapter 7: ATM Monitoring .................................................................................... 29
Preconditions..................................................................................................................... 29
ATM Logon Monitoring Workflow.................................................................................. 30
ATM Transaction Monitoring Workflow ......................................................................... 31
Chapter 8: Maintenance Workflow ..................................................................... 33

Maintenance Workflow..................................................................................................... 33
Chapter 9: Extra Credential Workflow ............................................................. 35

Credential Types ............................................................................................................... 35
Basic Credential Workflow............................................................................................... 36
Challenge Question Workflow.......................................................................................... 37
Chapter 10: Client-Managed Authentication ............................................... 41

Option 1............................................................................................................................. 41
Workflow ................................................................................................................... 41
Option 2............................................................................................................................. 43
Workflow ................................................................................................................... 43
Chapter 11: Transaction Notification Workflow ........................................ 47

Transaction Notification Workflow .................................................................................. 47
Contents 5
Chapter 12: Customer Service Workflows .................................................... 49

Locking a User Account ................................................................................................... 50
Unlocking a User .............................................................................................................. 50
Resetting a User Account.................................................................................................. 51
Deleting a User Account ................................................................................................... 52
Partially Reenrolling a User.............................................................................................. 53
Terminating Authentication Sessions ............................................................................... 54
User Scenarios for Terminating Authentication Sessions ......................................... 55
Chapter 13: Out-Of-Band Email Authentication Workflow ................. 57

Chapter 14: Out-Of-Band Phone Authentication Workflow ............... 61
Chapter 15: Knowledge-Based Authentication Workflow ................... 65
Chapter 16: Out-Of-Band SMS Authentication Workflow .................... 69
Chapter 17: One-Time Password Authentication Workflow .............. 73
Chapter 18: Failed Authentication Workflow .............................................. 77
Chapter 19: Sample SOAP Message Flows.................................................. 81
Allow Action Sample SOAP Message Flow .................................................................... 81
Create User with Binding SOAP Request for Allow Action..................................... 82
Create User with Binding SOAP Response for Allow Action .................................. 83
Analyze Session Sign in SOAP Request for Allow Action....................................... 85
Analyze Session Sign in SOAP Response for Allow Action ................................... 86
Update User with Unbinding SOAP Request for Allow Action .............................. 87
Update User with Unbinding SOAP Response for Allow Action ............................ 88
Knowledge-Based Authentication Sample SOAP Message Flow .................................... 89
Create User SOAP Request for KBA ....................................................................... 90
Create User SOAP Response for KBA...................................................................... 91
Analyze SOAP Request for KBA .............................................................................. 92
Analyze SOAP Response for KBA ........................................................................... 93
Challenge SOAP Request for KBA .......................................................................... 94
Challenge SOAP Response for KBA ........................................................................ 95
Authenticate SOAP Request for KBA....................................................................... 97
Authenticate SOAP Response for KBA (Failed)....................................................... 98
Authenticate SOAP Response for KBA (Pending).................................................... 99
Authenticate SOAP Response for KBA (Successful).............................................. 101
Out-of-Band Email Sample SOAP Message Flow ......................................................... 102
Create User SOAP Request for OOB Email............................................................ 103
Create User SOAP Response for OOB Email ......................................................... 104
Update User SOAP Request for OOB Email........................................................... 105
Update User SOAP Response for OOB Email ........................................................ 106
Analyze SOAP Request for OOB Email ................................................................. 107
Analyze SOAP Response for OOB Email ............................................................... 108
Challenge SOAP Request for OOB Email ............................................................. 109
6 Contents
Challenge SOAP Response for OOB Email .............................................................110

Authenticate SOAP Request for OOB Email ...........................................................111
Authenticate SOAP Response for OOB Email (Failed) ...........................................112
Authenticate SOAP Response for OOB Email (Success) ........................................113
Out-of-Band Phone Sample SOAP Message Flow..........................................................114
Create User SOAP Request for OOB Phone ...........................................................115
Create User SOAP Response for OOB Phone..........................................................116
Analyze SOAP Request for OOB Phone ..................................................................117
Analyze SOAP Response for OOB Phone ...............................................................118
Challenge SOAP Request for OOB Phone ..............................................................119
Challenge SOAP Response for OOB Phone............................................................ 120
Query Authentication Status SOAP Request for OOB Phone................................. 121
Query Authentication Status SOAP Response for OOB Phone (Failed)................. 122
Query Authentication Status SOAP Response for OOB Phone (Success) .............. 123
Out-of-Band SMS Sample SOAP Message Flow........................................................... 124
Create User SOAP Request for OOB SMS ............................................................. 125
Create User SOAP Response for OOB SMS........................................................... 126
Update User SOAP Request for OOB SMS ............................................................ 127
Update User SOAP Response for OOB SMS.......................................................... 128
Analyze SOAP Request for OOB SMS ................................................................... 129
Analyze SOAP Response for OOB SMS ................................................................ 130
Challenge SOAP Request for OOB SMS ............................................................... 131
Challenge SOAP Response for OOB SMS.............................................................. 132
Authenticate SOAP Request for OOB SMS............................................................ 133
Authenticate SOAP Response for OOB SMS (Failed)............................................ 134
Authenticate SOAP Response for OOB SMS (Successful)..................................... 135
One-Time Password Sample SOAP Message Flow ....................................................... 135
Create User SOAP Request for OTP ....................................................................... 136
Create User SOAP Response for OTP..................................................................... 137
Analyze SOAP Request for OTP............................................................................. 138
Analyze SOAP Response for OTP .......................................................................... 139
Challenge SOAP Request for OTP ......................................................................... 140
Challenge SOAP Response for OTP ...................................................................... 141
Authenticate SOAP Request for OTP...................................................................... 142
Authenticate SOAP Response for OTP (Failed)...................................................... 143
Authenticate SOAP Response for OTP (Successful) ............................................. 144
Secret Questions Sample SOAP Message Flow ............................................................. 144
Create User SOAP Request for Secret Questions ................................................... 145
Create User SOAP Response for Secret Questions ................................................ 146
Analyze SOAP Request for Secret Questions ......................................................... 147
Analyze SOAP Response for Secret Questions ....................................................... 148
Challenge SOAP Request for Secret Questions ...................................................... 149
Challenge SOAP Response for Secret Questions .................................................... 150
Authenticate SOAP Request for Secret Questions ................................................. 151
Contents 7
Authenticate SOAP Response for Secret Questions (Failed) ................................. 152

Authenticate SOAP Response for Secret Questions (Successful) .......................... 153
Query Sample SOAP Messages...................................................................................... 154
Query SOAP Request for KBA ............................................................................... 154
Query SOAP Response for KBA............................................................................. 155
8 Contents
1 Understanding the Workflows

Types of Workflows
Sign in Types
Transaction Behaviors
This chapter provides an overview of the recommended workflows for the RSA
Adaptive Authentication (On-Premise) system and describes logon types and
Transaction Behaviors that relate to these workflows.
Types of Workflows
Main Workflows. Allow end users to safely sign in and make transactions in your
system.
Dependent Workflows. Allow end users to perform additional activities in your
system and allow you to interact with the Adaptive Authentication system.
Customer Service Workflows. Allow customer support representative to help
users with accounts.
Credential Workflows. Specific to different credential types. For more
information, see Chapter 9, Extra Credential Workflow.
Main Workflows
The following table describes the main workflows that allow end users to safely sign
in and make transactions in your system.
Workflows Description Dependent Workflows
Logon Authentication Allows a user to sign in to your system. Enrollment

There are several different workflows in this category, User Maintenance
depending on how you implement your system. Extra Credential
See Chapter 2, Authentication Workflow..
Sign in with Risk-Based Authentication.
Sign in with Positive Device Identification Only.
For more information, see Sign in Types on
page 11.
Logon Monitoring Allows a user to sign in to your system.

Collects information and flags potentially risky users.
Designed to have no impact on the user experience.
See Chapter 3, Logon Monitoring Workflow..
1: Understanding the Workflows 9

Transaction Checks the risk of a given user transaction after Enrollment

Authentication successful sign in to the Adaptive Authentication Sign in
system.
User Maintenance
For example, you can perform risk analysis on a user
Extra Credential
transferring monies to outside accounts, paying bills,
or making a stock purchase.
See Chapter 4, Transaction Authentication
Workflow..
Transaction Monitoring Collects information on user-specific transaction.

Flags suspicious transactions.
Passive workflow.
See Chapter 6, Transaction Monitoring Workflow..
Dependent Workflows
The following table describes dependent workflows that support the main workflows.
These workflows allow end users to perform additional activities in your system and
allow you to interact with the Adaptive Authentication system.
Enrollment Enrolls a user into the Adaptive Authentication

system.
User Maintenance Allows a user to update account information, such Enrollment

as challenge questions.
Extra Credential Allows a user to perform further authentication Enrollment

for the Adaptive Authentication system. Sign in
Used with sign in and transaction Transaction Authentication
authentication to further authenticate a
User Maintenance
potentially risky user.
Client-Managed Allows you to use your own authentication Sign in

Credentials processes instead of the Adaptive Authentication
extra credential workflow
Transaction Notification Allows your institution to send additional Transaction Notification

information to the Adaptive Authentication Extra Credential
system.
10 1: Understanding the Workflows

Customer Service Workflows

The table below describes the workflows that allow a customer service representative
to help users with accounts or allow users to manage their own accounts.
Unlocking a User Account Allows a customer service Enrollment

representative to unlock a user who has Sign in Authentication, Transaction
locked himself or herself out of an Authentication or both
account.
Locking a User Account Allows a customer service Enrollment

representative to lock a potentially Sign in Authentication, Transaction
compromised account. Authentication or both
User Maintenance
Resetting a User Account Allows a customer service Enrollment

representative to unlock and reset a User Maintenance
locked user account in a situation
where the user does not know the
answers to the challenge questions.
Deleting a User Account Allows a customer service Enrollment

representative to delete an account.
Partially Reenrolling Allows a customer to partially reenroll Locking a User Account

after being locked out of an account. Unlocking a User Account
Sign in Types
The table below describes sign in types that relate to the various workflows.
Sign in Types Description
Sign in and Risk-based Authentication Authenticates users based on several factors, such as
network information, user information, positive device
identification, and user profiling.
Users with high risk scores are challenged.
(Optional) High-risk user logons can be flagged for
review in the Case Management application by
defining the policy action of the rule in the Policy
Management application. For more information, see
the Back Office Users Guide.
1: Understanding the Workflows 11

Sign in Types Description
Sign in and Positive Device Identification Only Authenticates users based primarily on device binding.
Other authentication factors include network
information and user information.
Users who use a new device are often challenged.
Users can register (bind) devices after they
successfully pass the challenge.
Sign in Monitoring Designed to have no impact on the current user

interface.
Collects information from the device and flags
potentially risky user logons. A fraud analyst can
review a marked case in the Case Management
application to determine if the case is actually fraud.
Does not challenge users.
Transaction Behaviors
The table below describes transaction types that relate to the various workflows.
Transaction Types Description
Transaction Authentication Challenges users when there are suspicious transaction events.
Both logon and payment events can be received.
(Optional) Case creation based on institution policies.
Transaction Monitoring Does not challenge users.

Both logon and payment events can be received.
Monitors transactions, flagging only cases with suspicious transaction
events.
Cases can be reviewed by analysts to determine if the cases are truly fraud.
12 1: Understanding the Workflows

2 Authentication Workflow
The authentication workflow allows a user to log on or perform an activity with a web
application portal. The RSA Adaptive Authentication (On-Premise) system
authenticates the user to determine if the user poses a potential risk.
If the risk score is low, the user is allowed to continue.
If the risk score is high, one of the following occurs:
The user is prompted to enter extra credential information to prove identity.
The user is denied access to the system if the risk is assessed as too high.
Potentially risky logons or transactions are flagged based on the action in the triggered
policies. The flagged events are sent to the Case Management application where the
events can be reviewed by fraud analysts. For more information, see the Back Office
Users Guide.
Preconditions:
The user state is VERIFIED.
The user has an account with the website of the organization. The user is enrolled
and is verified.
2: Authentication Workflow 13
The following figure illustrates the general message flow during an authentication
procedure. Out-of-band email authentication has been used in this example.
User Browser Organization's Web Site Adaptive Authentication
1. Request logon/initiate transaction
2. Display logon/transaction form
3. Gather device data (IP address, Browser information,

fingerprint, deviceTokenCookie, deviceTokenFSO)
4. Submit form details + device data
5. Call Analyze to calculate risk score
6. Calculate the
risk score and
apply policies
7. Respond with the recommended action and
available challenge methods
(In this example, high risk score is generated and the user is challenged)
8. Call Challenge
9. Respond with the challenge questions

(In this example, challenge questions are used)
10. Challenge user for secondary authentication
11. Submit the answers
12. Call Authenticate
13. Respond with authentication status
14. Display the main page
Authentication Workflow:
1. The user requests to log on or initiates a transaction to the organizations web
application.
2. The organizations web application displays the logon or transaction page.
3. The data-gathering JavaScript executes as the logon page loads and collects the
device data, like the IP address, browser information, fingerprint,
deviceTokenCookie, and deviceTokenFSO.
4. The user enters the logon or transaction details and clicks the submit button. The
device data is sent along with the event data.
5. The organization verifies the user credentials.
14 2: Authentication Workflow
6. The web application of the organization sends an analyze request message. The
device data is passed along with the user details.
The analyze request must include the device data, browser information, IP
address, user name, user type, action type, and event type.
For sample SOAP message, see Analyze SOAP Request for OOB Email on
page 107.
7. The information in the analyze request is processed by the RSA Risk Engine, and
a risk score is calculated.
8. The Adaptive Authentication system sends an analyze response with the
recommended policy action and the options for secondary authentication. In this
example, challenge questions are used.
Note: By default, challenge questions are used as the secondary

authentication method.
For a sample SOAP message, see Analyze SOAP Response for OOB Email on
page 108.
9. The website sends a challenge request to retrieve information for secondary
authentication. In this example, secondary authentication is done by challenge
questions.
The challenge request must include the device data, browser information, IP
address, sessionId, transactionId, and challenge details.
Note: Ensure to include sessionId and transactionId.
For sample SOAP message, see Challenge SOAP Request for OOB Email on
page 109.
10. The Adaptive Authentication system sends a challenge response with the
questions.
For a sample SOAP message, see Challenge SOAP Response for OOB Email
on page 110.
11. The web application of the organization prompts the user for secondary
authentication.
12. The user enters the answer and clicks the submit button.
The device forensic data must be sent along with the user's answers.
13. The web application of the organization sends the authenticate request message.
The device forensic data is passed along with the users answers.
The authenticate request must include the device data, browser information, IP
address, sessionId, transactionId, and answer to the challenge.
For a sample SOAP message, see Authenticate SOAP Request for OOB Email
on page 111.
2: Authentication Workflow 15
14. The Adaptive Authentication system sends an authenticate response with the
authentication status. In this example, the user is successfully authenticated.
For a sample SOAP message, see Authenticate SOAP Response for OOB Email
(Success) on page 113.
15. The secure page is displayed to the user. (Optional) The user may choose to bind
the device.
16 2: Authentication Workflow
3 Logon Monitoring Workflow

The logon monitoring workflow is an alternative form of logon security that RSA
provides to customers. This workflow allows you to observe user logon activities and
calculate a risk score for each logon.
In this workflow, the RSA Adaptive Authentication (On-Premise) system integrates
with the website of the organization, while retaining the existing user experience. The
necessary information is collected, risk analysis is performed, and potentially risky
users are flagged without impacting the user experience. Flagged logons are sent to
the Case Management application where the logons can be reviewed by fraud
analysts.
Preconditions:
The user has an account with the website of the organization.
The following figure illustrates the message flow during the logon monitoring
procedure. Each step involved in this procedure is described in the sections that
follow.
1. Request logon
2. Display logon form

4. Submit logon details + device data
5. Verify user credentials

7. Calculate the risk score

and apply policies
8. Respond with the recommended action

9. Display the main page regardless of recommended action
Logon Monitoring Workflow:

1. The user requests to log on to the website of the organization.
2. The website prompts the user to enter the user name and password.
device forensic data.
3: Logon Monitoring Workflow 17

4. The user enters the user credentials and clicks the submit button. The device
forensic data is sent along with the user credentials.
6. If the user authentication is successful, the website of the organization sends the
analyze request message. The device forensic data is passed along with the user
details.
The following elements must be included in the SOAP message:
ANALYZE request:
genericActionTypes=GET_USER_STATUS/GET_PHRASE devicePrint,
ipAddress, userName, userType, eventType=SESSION_SIGNIN,
riskType=ALL
Note: If the user authentication fails, your application must call the notify
request and pass the user and device forensic data to the Adaptive
Authentication system for anti-phishing purposes. For example,
NOTIFY request: eventType=FAILED_LOGIN_ATTEMPT,
devicePrint, ipAddress
7. The Risk Engine processes the information in the analyze request and applies
policies.
8. The Adaptive Authentication system sends an analyze response with the result.
Some of the following analyze response elements are returned in the SOAP
message:
ANALYZE response: deviceToken, actionCode=ALLOW
9. The secure page is displayed to the user.
Best Practices for Logon Monitoring

RSA recommends the following best practices to integrate logon monitoring in your
system:
Make sure to send device forensic information, such as IP address, browser
cookie, Flash Shared Object, and device fingerprints, to the Adaptive
Authentication system for every event using the analyze method, not just for
logon events. This additional data improves the risk assessment capabilities.
Make sure to always read the device token and note the token returned in the
response message from the Adaptive Authentication system. Every time that you
present the device token to the Adaptive Authentication system, some of its
internal parameters are updated. Therefore, the latest token must be updated on
the device to protect against token theft.
Make sure to call the notify request and pass the user and device forensic data to
the Adaptive Authentication system in case the user authentication fails.
18 3: Logon Monitoring Workflow

4 Transaction Authentication Workflow

Transaction authentication is the process of analyzing a users online transaction for
potential risk. When a verified user who has successfully logged on to your system
tries to perform certain types of transactions (as dictated by your policies), the
transaction authentication workflow is triggered. This process returns a risk score.
If the risk score is low, the user is allowed to continue the transaction.
If the risk score is high, the user is challenged with one of the challenge
mechanisms before being able to proceed with the transaction.
Potentially risky logons are flagged based on the action in the triggered policies. The
flagged logons are sent to the Case Management application where the transactions
can be reviewed by fraud analysts. For more information, see the Case Management
Users Guide.
Preconditions:
The user has successfully logged on to the website of the organization.
The following figure illustrates the general message flow during the transaction
authentication procedure. Challenge questions authentication has been used in this
example. Each step involved in this procedure is described in the sections that follow.
1. Initiate transaction
2. Display the transaction page
3. Gather device data (IP address, Browser information, fingerprint)
4. Submit transaction details + device data
6. Calculate the risk

score and apply
7. Respond with the recommended action and policies
available challenge methods
(In this example, high risk score is generated and the user is challenged)
8. Call Challenge
10. Challenge user for secondary authentication (In this example, challenge questions are used)

14. Display the transaction success page
4: Transaction Authentication Workflow 19

Transaction Authentication Workflow:

1. The user initiates a transaction on the website of the organization.
2. The website displays the transaction page.
3. The data-gathering JavaScript executes as the page loads and collects the device
forensic data.
4. The user enters the transaction details and clicks the submit button. The device
forensic data is sent along with the transaction details.
5. The website of the organization sends the analyze request message. The device
forensic data is passed along with the user details.
ANALYZE request: genericActionTypes=GET_USER_STATUS,
devicePrint, ipAddress, userName, userType,
eventType=PAYMENT, transactionData, riskType=ALL
policies.
7. Adaptive Authentication sends an analyze response message with the
recommended action and the list of available challenge methods. The list of
challenge methods consists of methods that the user selected during enrollment.
The organization can select one of the available challenge methods for secondary
authentication. In this example, challenge questions are used.
The following elements are returned in the SOAP message:
ANALYZE response: deviceToken, bindingType=NONE, sessionId,
transactionId, userStatus=VERIFIED, credentialType=QUESTION,
actionCode=CHALLENGE
8. The website sends the challenge request message to retrieve information for
secondary authentication. In this example, secondary authentication is done by
challenge questions.
CHALLENGE request: sessionId, transactionId,
challengeQuestionChallengeRequest(numberOfQuestion),
9. Adaptive Authentication sends a challenge response with the questions.
CHALLENGE response: deviceToken, sessionId, transactionId,
userStatus=VERIFIED, challengeQuestion
10. The website of the organization prompts the user for secondary authentication.
11. The user enters the answers and clicks the submit button.
The device forensic data must be sent along with the user's answers.
12. The website of the organization sends the authenticate request message. The
device forensic data is passed along with the users answers.
AUTHENTICATE request: devicePrint, sessionId, transactionId,
deviceToken, ipAddress, challengeQuestion(userAnswer)
20 4: Transaction Authentication Workflow

13. Adaptive Authentication sends an authenticate response with the authentication

status. In this example, the user is successfully authenticated.
AUTHENTICATE response: deviceToken, sessionId,
transactionId, authStatusCode=SUCCESS
14. The transaction success page is displayed to the user.
Best Practices for Transaction Authentication

RSA recommends the following best practices to integrate transaction authentication
in your system:
Make sure to send device forensic information, such as IP address, browser
cookie, Flash Shared Object, and device fingerprints, to the Adaptive
Authentication system for every event using the analyze method, not just for
logon events. This additional data improves the risk assessment capabilities.
Make sure to always read the device token and note the token returned in the
response message from Adaptive Authentication. Every time that you present the
device token to Adaptive Authentication, some of its internal parameters are
updated. Therefore, the latest device must be written back onto the device to
protect against token theft.
Make sure to get the sessionId and transactionId from the response and use these
values for the subsequent calls until the challenge process is complete and the user
is authenticated.
4: Transaction Authentication Workflow 21

5 Enrollment Workflow
Enrollment is the process of registering a new user on the RSA Adaptive
Authentication (On-Premise) system. Enrollment is also referred to as initial data
collection. During enrollment, a user is prompted to enter or choose from the
following enrollment options:
Challenge questions
Contact information, such as phone number or email address for out-of-band
credentials
Other credential information
Note: Consult with RSA before activating this workflow.
Preconditions:
The user state is NOTENROLLED or UNVERIFIED.
The user has been chosen for enrollment by the organization.
The user has an account with the website of the organization.
The Risk Engine is enabled.
The Risk Engine has been trained by loading historical data or by using the system
in silent mode for at least two months.
5: Enrollment Workflow 23
The following figure illustrates the message flow during the collection procedure for
enrollment. Each step involved in this procedure is described in the section that
follow.
Note: The organization must verify the transaction as non-risky before proceeding
with the collection procedure.
Enrollment workflow
1. The user requests to log on to the website of the organization.
2. The website prompts the user to enter the user name and password.
24 5: Enrollment Workflow
device data, like the IP address, browser information, fingerprint,
4. The user enters the user credentials and clicks the submit button. The device
forensic data is sent along with the user credentials.
5. The organizations web application verifies the user credentials.
6. If the user authentication fails, the application must send a request message to the
notify method and pass the user and device forensic data to the Adaptive
Authentication system for anti-phishing purposes.
The notify request must include the event type, device data, browser information,
and IP address.
7. If the user authentication is successful the organizations web application sends
the analyze request message. The device forensic data is passed along with the
user details.
The analyze request must contain the device data, browser information, IP
address, user name, user type, and event type.
For a sample SOAP message, see Analyze SOAP Request for OOB Email on
page 107.
policies.
recommended policy action. In this example, the user is allowed to continue the
enrollment process.
page 108.
10. The user is directed to the secure page with a link to the Enrollment page.
Optionally, the Enrollment page may be automatically displayed to users who are
not yet enrolled.
11. The user clicks on the enrollment link.
12. The website of the organization sends a createUser request to create a record for
the user.
The createUser request must include the device data, browser information, IP
address, action type, and challenge question action type.
For a sample SOAP message, see Create User SOAP Request for OOB Email
on page 103.
13. The Adaptive Authentication system sends a createUser response with challenge
questions.
For a sample SOAP message, see Create User SOAP Response for OOB Email
on page 104.
14. The form in which to enter the enrollment details is displayed to the user.
The web application allows the user to choose from several different enrollment
options determined by the organization.
5: Enrollment Workflow 25
15. The user enters the enrollment details. For example, the user selects the challenge
questions and enters the answers.
16. The user reviews the selections and the information entered and then confirms
enrollment. The enrollment data is submitted to the website of the organization.
17. The website of the organization sends the updateUser request message. The
Adaptive Authentication system updates the user record in the database.
The updateUser request must include the device data, browser information, IP
address, user status, and challenge question action type.
Note: On successful enrollment, the user status is set to VERIFIED.
For a sample SOAP message, see Update User SOAP Request for OOB Email
on page 105.
18. The Adaptive Authentication system returns the update confirmation.
For a sample SOAP message, see Update User SOAP Response for OOB Email
on page 106.
19. The main page of the organizations web application is displayed to the user.
Postconditions:
(Optional) The user device is bound if selected by the user.
26 5: Enrollment Workflow
6 Transaction Monitoring Workflow

The transaction monitoring workflow is an alternative form of transaction security that
the RSA Adaptive Authentication (On-Premise) system provides to customers. This
workflow allows you to observe user transaction activities and calculate a risk score
for each transaction.
This workflow is designed to collect the necessary information, perform risk analysis,
and flag potentially risky users without impacting the user experience. Flagged
transactions are sent to the Case Management application where the transactions can
be reviewed by fraud analysts.
Important: Make sure to send as much information as possible using the notify
method.
Preconditions:
The user has successfully logged on to the website of the organization.
The following figure illustrates the message flow during the transaction monitoring
procedure. Each step involved in this procedure is described in the sections that
follow.
1. Initiate transaction
2. Display the transaction page

4. Submit transaction details + device data

score and apply
policies
7. Respond with the review or allow action
8. Display the transaction success page

regardless of recommended action
Transaction Monitoring Workflow:

1. The user requests to initiate a transaction on the website of the organization.
2. The website displays the transaction page.
6: Transaction Monitoring Workflow 27

3. The data-gathering JavaScript executes as the page loads and collects the device
forensic data, deviceTokenCookie, and deviceTokenFSO.
4. The user enters the transaction details and clicks the submit button. The device
forensic data is sent along with the transaction details.
The analyze request must contain the device data, browser information, IP
page 107.
policies.
7. The Adaptive Authentication system sends an analyze response with the result.
page 108.
8. The transaction success page is displayed to the user regardless of the
recommended policy action.
28 6: Transaction Monitoring Workflow

7 ATM Monitoring
The ATM protection module focuses on monitoring ATM activities. The workflows
for this module track logon and monetary transactions. The workflows are designed to
allow you to observe user logon or transaction activity and calculate a risk score for
each activity while being transparent to the user.
In these workflows, the RSA Adaptive Authentication (On-Premise) system receives
information from the ATM server. Specifically, this server collects ATM activity
information for transfer to the Risk Engine.
ATM activity information is loaded into the Adaptive Authentication system by using
either the on-line SOAP API or the Batch Loader utility. For more information about
the application of the Batch Loader utility in this process, see the Operations Guide.
The Risk Engine analyzes this information, resulting in a risk score and recommended
policy action, which triggers ATM policy rules. A new case is created for each flagged
event if the triggered ATM policy rule is defined for case creation.Transactions
flagged as suspected fraud are sent to the Case Management application where the
transactions can be reviewed by fraud analysts.
Preconditions
The Adaptive Authentication system only transfers the information to the Risk Engine
for ATM processing, if the Analyze request includes the following:
The channel indicator in the SOAP call is ATM.
An ATM payload, such as atmID, is included in the SOAP call.
7: ATM Monitoring 29
ATM Logon Monitoring Workflow

The following figure shows the ATM logon monitoring workflow.
ATM User ATM Device ATM Server Adaptive Authentication
1. Initiates log on
2. Collects the users credentials
and the card information
3.Transfers collected data to the ATM Server
4. Collects the ATM device

information
5.Transfers collected ATM-related

data to AA using either the API or
the Batch Loader utility
6. Passes the transferred
6a. Responds with Allow action data to the Risk Engine
6b. Displays log on success to calculate the Risk Score
7. Creates a new case if the

event is flagged as suspected
fraud and the ATM policy rule
triggered is defined for case
creation.
During ATM logon monitoring, the following occurs:

1. The user logs on to an ATM device.
2. The ATM collects the users credentials and the users card information.
3. The collected information is transferred to the ATM server.
4. The ATM server collects the ATM device information.
5. All the collected information is transferred to the Adaptive Authentication system.
6. The Adaptive Authentication system passes the information to the Risk Engine for
risk analysis, which results in a risk score.
In parallel to this step, the logon to the ATM device is allowed:
a. The ATM server responds with an Allow action, regardless of the analysis
results.
b. A logon success response is displayed on the ATM device.
7. If the analysis result is suspected fraud, the event is flagged. If the triggered ATM
policy rule is defined for case creation, a new case is created and sent to the Case
Management application, where the transaction can be reviewed by a fraud
analyst.
30 7: ATM Monitoring
ATM Transaction Monitoring Workflow

The following figure shows the ATM transaction monitoring workflow.
ATM User ATM Device ATM Server Adaptive Authentication
1. Initiates transaction
2. Collects the users credentials
and the transaction data
3.Transfers collected data to the ATM Server
4. Collects the ATM device

information
5. Transfers collected ATM transaction data

to AA using either the API or the Batch
Loader utility
6. Passes the transferred data
to the Risk Engine
6a. Responds with transaction success to calculate the Risk Score
6b. Displays transaction success
7. Creates a new case if the
event is flagged as suspected
fraud and the ATM policy rule
triggered is defined for case
creation.
During ATM transaction monitoring, the following occurs:

1. The user enters one of the following transactions on to the ATM device:
Card PIN Change
Change Password
Deposit
Failed Login Attempts
Login
Money Transfer
View Statement
Withdrawal
2. The ATM collects the users information and the transaction information.
3. The collected information is transferred to the ATM server.
4. The ATM server collects the ATM device information.
5. All the collected information is transferred to the Adaptive Authentication system.
7: ATM Monitoring 31
6. The Adaptive Authentication system passes the information to the Risk Engine for
risk analysis, which results in a risk score.
In parallel to this step, the transaction entered on to the ATM device is allowed:
a. The ATM server responds with transaction success, regardless of the analysis
results.
b. Transaction success is displayed on the ATM device.
7. If the analysis result is suspected fraud, the event is flagged. If the triggered ATM
policy rule is defined for case creation, a new case is created. Flagged transactions
are sent to the Case Management application where the transactions can be
reviewed by fraud analysts.
32 7: ATM Monitoring
8 Maintenance Workflow
Maintenance is the process of allowing a user to change enrollment information. This
workflow assumes that the user has successfully enrolled and logged on to the RSA
Adaptive Authentication (On-Premise) system.
Maintenance Workflow
1. Enable maintenance. A user chooses to modify user information.
2. Change or add challenge questions and answers. (Optional) The user wants to
modify the challenge questions and answers. Your application must do the
following:
Retrieve the list of questions to display to the user.
Allow the user to select new questions and provide new answers.
Allow the user to modify the answers to existing questions.
3. Change or add user out-of-band information. (Optional) The user wants to
modify out-of-band information.
Your application should collect the new information and perform data validation if
required. The Adaptive Authentication system allows for the management of
multiple emails and phone numbers of a given user.
4. Change or add other credentials. (Optional) The user adds or changes other
credential information. Your application should collect the new information and
send it to the Adaptive Authentication system.
5. Confirm user selection. The user reviews the selections and confirms enrollment.
After changes are confirmed, the Adaptive Authentication system updates the user
record in the database.
8: Maintenance Workflow 33
The following figure displays the maintenance workflow.
34 8: Maintenance Workflow
9 Extra Credential Workflow

If a user is determined to be risky in either a logon or transaction authentication
workflow, the extra credential workflow is performed to help authenticate the user.
If your institution supports your own authentication mechanisms, the RSA Adaptive
Authentication (On-Premise) system can support your existing workflows. See
Chapter 10, Client-Managed Authentication.
Note: You should be aware of the following time-out configuration issues that are
relevant to all authentication methods:
If the user is assigned to only one authentication method, the application checks
the Administration Console parameter Fraud Notification Before Session
Time-out for that authentication method. If this parameter is True, the Risk
Engine is notified of a session with suspected fraud. In this situation, the Risk
Engine gathers information from the session about user activity until the Adaptive
Authentication application notifies the Risk Engine that the session is not
suspected fraud.
If the parameter Fraud Notification Before Session Time-out is False, the
application waits for the session to expire before notifying the Risk Engine of the
authentication result. In this situation, the authentication result is Failure unless
the session ends in success, prior to session expiration.
The Adaptive Authentication application checks the number of sessions currently
open for the user, before opening a new session for the user.
If the number of open sessions for the user is greater than the value of the
Administration Console parameter Maximum Open Sessions per User, the
session is not opened.
For more information, see the Release Notes.
Credential Types
Credential Type Description
Challenge Questions The user provides answers to a set of questions chosen by the
institution.
Examples: What is your mothers maiden name? and What is the
name of your first pet?
One-Time Password During challenge, a one-time password (token) is returned in the

response payload.
9: Extra Credential Workflow 35

Credential Type Description
Out-of-Band Phone The user is called on a phone number that the user provided during
enrollment.
The user is prompted to enter a one-time password, which is sent
through an online application on the users phone.
Out-of-Band Email The user is contacted at an email address that the user provided during
enrollment.
The user is prompted to enter a one-time password, which is sent in
the email message.
Out-of-Band SMS The user is sent an SMS on the mobile device that the user registered
during enrollment.
The user is prompted to enter a one-time password, which is sent in
the SMS.
Knowledge-Based Authentication The user answers questions in an automated step-by-step process.

The answers to each question are scored in real time.
Generic Authentication Plug-In Authentication uses customer-defined authentication credentials.
Basic Credential Workflow

1. Initiate an activity. The user initiates a logon or transaction.
2. Recommend an action.
a. The Adaptive Authentication system determines that the activity is potentially
risky and determines that extra credentials are required to help further
authenticate the user.
b. The user can be prompted to provide one of the following types of credentials:
Answers to challenge questions
Out-of-band phone, out-of-band SMS, or out-of-band email
authentication
Generic authentication plug-in
3. Request and collect credentials. Your system presents the credential request.
For challenge questions, your organization collects the user answers.
For out-of-band phone, out-of-band SMS, and out-of-band email
authentication, the Adaptive Authentication system collects information from
the user.
4. Check the answer.
Collected information is checked by the Adaptive Authentication system:
Does the answer match existing information?
Has the user exceeded the preset number of answer attempts for a question?
36 9: Extra Credential Workflow

Has the user exceeded the allowed number of attempts?

Can additional fallback credentials be used to help authenticate the user?
5. Determine the outcome. Based on the check that the Adaptive Authentication
system performs, the user is allowed or denied access to your application.
The following figure displays the basic credential workflow.
Challenge Question Workflow

1. Initiate an activity. The user initiates a logon or transaction.
a. The Adaptive Authentication system determines that the activity is potentially
risky and determines that challenge questions are required to help further
authenticate the user.
b. Your system requests the users challenge questions from the Adaptive
Authentication system and then displays a question for the user.
3. Collect the users answers.
Your system does the following:

a. Gathers the users answers

b. Performs data validations on the answer
c. Sends the answers to the Adaptive Authentication system for matching
4. Check information and determine an outcome.
After the credential types are collected, the Adaptive Authentication system
performs the following checks:
Does the answer match?
If yes, the user is allowed to continue with the transaction.
If no, the next check is performed by the Adaptive Authentication system.
Did the user exceed the preset number of answer attempts?
If no, the user is allowed to continue with the transaction.
If yes, the next check is performed by the Adaptive Authentication
system.
Did the user exceed the total number of attempts a user is allowed?
If no, the user is allowed to continue with the transaction.
If yes, the next check is performed by the Adaptive Authentication
system.
Can additional fallback credentials be used to help authenticate the user?
If yes, your system requests the users challenge questions from the
Adaptive Authentication system and then displays a question for the user.
If no, the user is denied access.
In the event that a user is denied access, subsequent actions include:
- locking the user out of the account
- preventing the user from completing the specific transaction
- allowing the user to continue a normal online transaction
- requiring the user to contact customer service for assistance
38 9: Extra Credential Workflow

The following figure displays the challenge questions workflow.

10 Client-Managed Authentication
If your institution supports its own authentication mechanism, the RSA Adaptive
Authentication (On-Premise) system can support your existing workflows and allow
you to use your mechanisms in the ways described in this chapter.
The client-managed authentication supports all available credential types: Challenge
Questions, OOB Phone or Email, and Generic Authentication Plug-In.
Note: You can request to bind a device using the Analyze method. If a challenge is
presented to the end user, whose device is in the process of being bound, the status of
the device is temporary. You cannot change the status of the device to persistent
using the Notify request. You also cannot change the status of the user from
VERIFIED or UNVERIFIED to LOCKOUT. For more information, see the section
about managing user accounts in the Back Office Users Guide. To change the status of
the device or of the user, use the updateUser or Authenticate methods after calling the
Notify method. For more information, see the Web Services API Reference Guide.
Option 1
You can use the Adaptive Authentication system to authenticate a users collected
information but your application maintains and presents the challenge to the user.
For example, your application uses its own challenge questions, and sends the users
collected answer and the users stored answer to the Adaptive Authentication system,
where the users answers are compared. This option allows you to make use of fuzzy
logic comparators when matching answers.
Workflow
For this workflow, the Adaptive Authentication system does not store the users
credential information, for example, answers to the challenge questions. Your
application should have some method for storing and retrieving the users credential
information.
The following workflow assumes that challenge questions are being used.
1. Initiate an activity. The user begins a logon or transaction activity.
The Adaptive Authentication system determines that the activity is potentially
risky.
The Adaptive Authentication system determines that extra credentials are
required to help further authenticate the user.
The Adaptive Authentication system informs your system of the need for
further authentication.
10: Client-Managed Authentication 41

3. Request and collect credentials.

Your application does the following:
a. Presents your challenge questions to the user
b. Collects the users given answers and performs any necessary data validation
c. Retrieves the users stored answers from your database
d. Sends all collected information to the Adaptive Authentication system.
4. Check the answer.
After receiving the data, the Adaptive Authentication system checks to see if the
answers match using the fuzzy logic comparators. The system sends a pass or fail
result back to your application.
5. Determine the outcome. Based on the result that is passed back, your application
determines the outcome. Possible outcomes include:
Requesting that the user try again
Allowing the user
Denying the user
Your application must keep track of the number of attempts the user has made.
6. Lock out user. (Optional) If the user has answered incorrectly too many times,
you need to lock out the user.
Note: In this workflow option, the Adaptive Authentication system does not
automatically lock out the users account. Your application needs to inform
the Adaptive Authentication system if a user needs to be locked out because
of too many failed attempts.
7. Generate case. (Optional) Depending on your policy, a case may be generated if

the user fails to authenticate.
42 10: Client-Managed Authentication

The following figure displays the client-managed credentials workflow.
Option 2
The user is challenged and authenticated separately from the Adaptive Authentication
system, and the authentication results are sent to the Adaptive Authentication system.
Workflow
For this workflow, the Adaptive Authentication system does not store the users
credential information, for example, answers to challenge questions. Your application
performs all the necessary authentication whenever the Adaptive Authentication
system makes that type of recommendation.
Note: The following flow uses Challenge Questions authentication for demonstration
purposes.

1. Initiate an activity. The user initiates a sign-in or transaction.

2. Recommend an action. The Adaptive Authentication system determines that the
activity is potentially risky and determines that extra credentials are required to
help further authenticate the user. The Adaptive Authentication system informs
your application of the need for further authentication.
3. Request, collect, and authenticate credentials. The application performs the
following actions:
a. Presents your challenge questions to the user
b. Collects the users given answers
c. Checks to see if the users answers match
4. Inform the Adaptive Authentication system. After your application has
determined the outcome, your application must inform the Adaptive
Authentication system of a result. Results include:
Did the user answer correctly?
How many times did the user answer incorrectly?
Should the user be locked out of the account?
Note: The Adaptive Authentication system does not automatically lock out the user
account. Your application needs to inform the Adaptive Authentication system if a
user needs to be locked out due to too many tries.
If your application does not inform the Adaptive Authentication system of the result of
your authentication, it is as if the challenge is abandoned. The activity is marked as
suspected fraudulent in the Case Management application.
44 10: Client-Managed Authentication

The following figure displays the client-managed credentials workflow.

11 Transaction Notification Workflow

In this workflow, the application notifies the RSA Adaptive Authentication
(On-Premise) system of any pertinent user activity that should be added to the user
history and of additional profile information, such as IP profile or payee profile. The
user activity can include any of the following actions:
Ordering new checks
Ordering a new card
Changing a password
Changing profile information, such as address or phone number
Transaction Notification Workflow

1. Initiate an activity. The user begins an activity that should be added to the user
history. These activities might not need risk analysis by the Adaptive
Authentication system.
2. Collect information. Your application collects required information and passes it
to the Adaptive Authentication system. Information that the application collects
can include any of the following:
Additional account information, such as account number or balance
Device token, such as Flash Shared Object or cookie
Device and network information, such as IP address or browser information
3. Store the information. The Adaptive Authentication system stores the
information for later use in additional risk analysis, user profile building, and,
potentially, case creation in the Case Management application, depending on your
policies.
11: Transaction Notification Workflow 47

The following figure displays the transaction notification workflow.
48 11: Transaction Notification Workflow

12 Customer Service Workflows

Several workflows relate to customer service. These workflows are performed either
through a customer service representative or by allowing the user to perform
necessary functionality.
Customer service workflows are used in conjunction with the Back Office
applications, such as the Customer Service application. These applications enable
customer service to work with users and accounts. The workflows include the
following actions:
Lock a user account. This workflow allows a customer service representative to
lock a user account for either of the following reasons:
A user believes an account is compromised and requests a lock on the
account.
Your system determines that a user account should be locked due to internal
policies.
Unlock a user account. This workflow allows a customer service representative
to unlock a user account that was locked due to one of several reasons:
The user failed authentication in the RSA Adaptive Authentication
(On-Premise) system, which automatically locks an account after a set
number of attempts.
The user requested that an account be locked due to a security compromise.
Your system determined that the account was a security risk and locked it.
Reset a user account. This workflow allows a customer service representative to
unlock and reset a locked user account in a situation where the user does not know
the answers to the challenge questions.
Delete a user account. This workflow allows a customer service representative to
delete a user account for reasons that include one of the following:
The user account is completely compromised.
The user is no longer with your organization.
Your application deems that the user account should be deleted.
Partial reenrollment of a user. After a customers account is unlocked, you can
have the user reenroll into the Adaptive Authentication system so that the user can
reenter account information, such as answers to challenge questions or new
out-of-band information.
Terminate Authentication Sessions. This workflow allows a customer service
representative to terminate abandoned open authentication sessions for a specified
user. The terminated sessions can be monitored using the user change history
value Reset Session (S). If the Administration Console parameter Open Case for
Events on Session Termination is set to True, a case is automatically opened for
each terminated session.
12: Customer Service Workflows 49

Locking a User Account

1. The customer service representative receives a request to lock a user account or
your system determined that the account was a security risk and locked it.
2. The customer service representative validates the users identity, if necessary.
3. The customer service representative submits a lock request to the system.
4. The user account is locked from any online activity until a resolution is reached.
The following figure displays the workflow of locking a user account.
Unlocking a User
1. The customer service representative receives a request to unlock a user account.
3. The customer service representative submits an unlock request to the Adaptive
4. One of the following occurs:
50 12: Customer Service Workflows

The user is required to log on and reestablish credential information if the user
forgot the challenge questions.
The user can log back on to your system without any other requirements.
The following figure displays the workflow of unlocking a user account.
Resetting a User Account

1. The customer service representative receives a request to reset a user account.
3. The customer service representative submits a reset request to the Adaptive
4. The user is set to RESET.
5. The user is required to log on and choose new challenge questions along with
corresponding answers.

The following figure displays the workflow of resetting a user account.
Deleting a User Account

1. The customer service representative receives a request to delete a user account or
your system determines that a user account should be deleted.
3. The customer service representative submits a delete request to the Adaptive
4. The user account is deleted.
After an account is deleted, you can reuse the account for another customer or for
the same customer by initiating the Enrollment action. If the account is reused by
the same user, the user must completely reenroll.

The following figure displays the workflow of deleting a user account.
Partially Reenrolling a User

When a user is locked out of an account, you can allow the user to partially reenroll,
for example, by choosing new challenges questions or providing new answers.
1. Identify the user.
a. The user logs on to your system.
b. Your system validates the user name as an existing user.
c. If the user name is not valid, your application can pass the user to the
Adaptive Authentication system for anti-phishing purposes.
2. Determine if user needs to be reenrolled. Check if the user has been recently
been unlocked from a locked state.
3. Bind the device ID. A second-factor device token is created and placed on the
users device.

4. Select partial reenrollment options. Because the information has been cleared,
the user selects enrollment options:
Select challenge questions. The user sets up challenge questions and
answers.
Add user credential information. The user adds credential information, such
as phone numbers for out-of-band (OOB) authentication.
5. Confirm user selection. The user reviews the selections and confirms enrollment.
After enrollment is confirmed, the Adaptive Authentication system updates the user
record in the database.
Note: You can combine multiple pages into one page for ease of use. Fewer pages
may lead to an increase in completed user enrollments.
The following figure displays the workflow of partially reenrolling a user account.
Terminating Authentication Sessions

The maximum number of open sessions allowed per user is defined in the Back Office
Administration Console. A policy rule to trigger an activity to open a case for each
terminated abandoned authentication session is defined in the Policy management
application.

1. A user attempts to log on to the application and is blocked due to the maximum
number of sessions open for the user.
2. The user calls the customer Service to inquire about the problem with the logon
process.
3. Using the Back Office Customer Service application, the RSA Customer Service
representative terminates all the open sessions for the user by pressing the
Terminate Authentication Sessions button in the User Details window.
The application updates the change history for the user with the Reset Session flag
(S) along with the date and time the user sessions were terminated.
4. If the Administration Console parameter Open Case for Events on Session
Termination is set to True, for each terminated authentication session, the Session
Reaper submits an event, for which the Event Puller opens a case in the Case
Management application.
5. A new session is opened for the user.
User Scenarios for Terminating Authentication Sessions

The following are some examples of user scenarios in which an authentication session
might be terminated.
An open authentication session for a user fails. The number of failure attempts has
not reached the maximum number of attempts allowed. The customer
representative decides to terminate the session for the user before all the allowed
authentication attempts have been exhausted.
The user attempts to log on to Adaptive Authentication (On-Premise). However,
the number of open sessions for the user has reached the maximum allowed for
that user. The customer representative decides to terminate the open sessions for
the user to allow the user to log on to the application.
The customer representative terminates the open sessions for a user. A case is
automatically opened for each terminated session because the Administration
Console parameter Open Case for Events on Session Termination is set to True.
The customer representative terminates the open sessions for a user. The user
monitors the terminated sessions for a user by reporting all the sessions flagged
Reset Session (S) in the user change history information.

13 Out-Of-Band Email Authentication Workflow

During a user logon or transaction, if the users action is found to be risky, the user is
prompted for secondary authentication. One of the challenge methods available for
secondary authentication is out-of-band (OOB) email authentication. In OOB email
authentication, the RSA Adaptive Authentication (On-Premise) system sends a
one-time password (OTP) to the user using the users registered email address. The
user must enter the one-time password to continue the activity.
Preconditions
The user is successfully enrolled for OOB email with the Adaptive Authentication
system.
13: Out-Of-Band Email Authentication Workflow 57

The following figure shows the general message flow during the OOB email
authentication. Each step involved in this procedure is described in the sections that
follow.

6. Calculate the
risk score and
7. Respond with the recommended action apply policies
and available challenge methods
(In this example, high risk score is generated and the user is challenged using OOB Email )
8. Call Challenge with oobEmailChallengeRequest
9. Generate
One Time
Password
10. Email the generated One Time Password to the user

14. Validate the following:

- OTP entered matches
- OTP has not expired
- OTP is not reused
OOB Email Authentication Workflow

1. The user requests to log on or initiates a transaction on the website of the
organization.
2. The website displays the logon or transaction page.
3. The data-gathering JavaScript runs as the page loads and collects the device data,
such as the IP address, browser information, fingerprint, deviceTokenCookie, and
deviceTokenFSO.
4. The user enters the logon or transaction details and clicks the submit button.
The device forensic data is sent along with the transaction details.
58 13: Out-Of-Band Email Authentication Workflow

address, user name, event type, and transaction data.
page 107.
policies.
7. The Adaptive Authentication system sends an analyze response message with the
recommended policy action and the list of available challenge methods. The list of
challenge methods consist of the methods that the user selected during enrollment.
The organization can select one of the challenge methods available for secondary
authentication. In this example, out-of-band (OOB) email is used.
page 108.
OOB email.
address, sessionId, transactionId, and OOB email challenge data.
For a sample SOAP message, see Challenge SOAP Request for OOB Email on
page 109.
9. The Adaptive Authentication system generates a one-time password for the given
activity and sends the challenge response.
For a sample SOAP message, see Challenge SOAP Response for OOB Email
on page 110.
10. The Adaptive Authentication system creates an email with the one-time password
and sends the email to the user.
12. User enters the answer and clicks the submit button.
The website must retrieve and send the device forensic data to the Adaptive
address, sessionId, transactionId, and OOB email data.
For a sample SOAP message, see Authenticate SOAP Request for OOB Email
on page 111.
14. The Adaptive Authentication system validates the data entered by the user against
the generated one-time password. The Adaptive Authentication system also
validates if the one-time password has expired or is reused.
13: Out-Of-Band Email Authentication Workflow 59

15. The Adaptive Authentication system sends an authenticate response message with
the authentication status.
For a sample SOAP message, see Authenticate SOAP Response for OOB Email
(Success) on page 113.
60 13: Out-Of-Band Email Authentication Workflow

14 Out-Of-Band Phone Authentication

Workflow
In out-of-band (OOB) phone authentication, the OOB phone service calls the end user
on the phone number collected during enrollment. The phone service provides the end
user with a one-time password (OTP). Your online system prompts the end user for
step-up authentication, and the end user must enter the OTP correctly to continue the
activity.
Your organization sends a challenge request to RSA Adaptive Authentication
(On-Premise) to initiate the OOB phone challenge. Your online system also sends
queryAuthStatus request to Adaptive Authentication to get the status of the
authentication.
Your online system receives the response message with the current status of the
authentication as follows:
If the phone authentication is complete, the response message indicates
SUCCESS or FAIL.
If the authentication is in-progress, the response message indicates PENDING for
If there are system errors during the authentication process, the response message
indicates NULL status.
14: Out-Of-Band Phone Authentication Workflow 61

The following figure shows the general message flow during the out-of-band (OOB)
Phone authentication. This workflow assumes that the end user is successfully
enrolled for OOB Phone with RSA Adaptive Authentication (On-Premise) and that
the end user status is verified.
(QG8VHU%URZVHU 2QOLQH6\VWHP 56$$GDSWLYH$XWKHQWLFDWLRQ
5HTXHVWORJRQRULQLWLDWHWUDQVDFWLRQ
'LVSOD\ORJRQRUWUDQVDFWLRQIRUP
*DWKHUGHYLFHGDWD
6XEPLWIRUPGHWDLOVDQGGHYLFHGDWD
9HULI\HQGXVHU
FUHGHQWLDOV
6HQGDQDO\]HUHTXHVWPHVVDJH
&DOFXODWHWKH
ULVNVFRUHDQG
DSSO\SROLF\
6HQGDQDO\]HUHVSRQVHPHVVDJH
6HQGFKDOOHQJHUHTXHVWPHVVDJH
*HQHUDWH
RQHWLPH
SDVVZRUG
6HQGFKDOOHQJHUHVSRQVHPHVVDJH
&KDOOHQJHHQGXVHUIRU
VHFRQGDU\DXWKHQWLFDWLRQ
6HQGRQHWLPHSDVVZRUGWRHQGXVHUWKURXJKSKRQH
6XEPLWWKHDQVZHUV
6HQGTXHU\$XWK6WDWXVUHTXHVWPHVVDJH
9DOLGDWH
RQHWLPH
SDVVZRUG
6HQGTXHU\$XWK6WDWXVUHVSRQVHPHVVDJH
'LVSOD\WKHPDLQSDJH
Out-of-Band Phone Authentication Workflow

1. The end user tries to log on to your online system or initiate a transaction.
2. The online system displays the logon or transaction page.
such as the IP address, browser information, device fingerprint,
62 14: Out-Of-Band Phone Authentication Workflow

4. The end user enters the logon or transaction details and clicks the submit button.
5. The online system verifies the end-user credentials.
6. The online system sends an analyze request message. The device forensic data is
passed along with the end-user details.
The analyze request must include the device data, user name, event type, and
transaction data.
7. The RSA Risk Engine processes the information in the analyze request and
calculates a risk score, and Adaptive Authentication applies the relevant policy.
challenge methods consists of the methods that the end user selected during
enrollment. The organization can select one of the challenge methods available for
step-up authentication. In this example, out-of-band (OOB) phone is used.
9. The online system sends a challenge request message to retrieve information for
step-up authentication.
The challenge request must include the device data, sessionId, transactionId, and
OOB phone challenge data.
10. Adaptive Authentication generates a one-time password (OTP) for the given
recommended policy action and the options for step-up authentication. For more
information about policies and authentication methods, see the Back Office Users
Guide.
12. Your online system prompts the end user for step-up authentication.
13. The OOB phone service calls the end user on the phone number collected during
enrollment. The phone service provides the end user with the one-time password.
14. The end user answers the phone and enters the OTP correctly within the
configurable time-out window measured from when the request message was sent
to the challenge method.
If the time-out window expires, the user is denied access and must try again. Your
system should allow for the end user to request another out-of-band message if the
end user does not receive the call.
15. Your online system sends a queryAuthStatus request message to Adaptive
Authentication with the OTP that the end user entered. Your online system must
send this request message within the time-out window. You need to continue
querying Adaptive Authentication until you receive a Success or Fail
queryAuthStatusResponse message.
14: Out-Of-Band Phone Authentication Workflow 63

16. Adaptive Authentication validates the one-time password that the end user entered
against the generated one-time password. Adaptive Authentication also checks
whether the one-time password has expired or is reused.
Adaptive Authentication sends a poll request for status to the Authentication
Plug-In service provider and receives a general status code from Authentication
Plug-In. Adaptive Authentication translates the general status codes received from
the Service Provider into channel status codes.
17. Adaptive Authentication returns a queryAuthStatus response message with the
result.
18. Your online system displays the secure page to the end user.
64 14: Out-Of-Band Phone Authentication Workflow

15 Knowledge-Based Authentication Workflow

During user logon or transaction, if the users action is found to be risky, the user is
secondary authentication is knowledge-based authentication (KBA).
KBA is a method to authenticate an identity based on the knowledge of personal
information, substantiated by a real-time interactive question-and-answer process.You
can apply KBA as an authentication method when creating rules in the Policy
Management application of the RSA Adaptive Authentication (On-Premise) system.
The Adaptive Authentication system works with the KBA Question Engine.
The user answers questions in an automated step-by-step process, and the answer to
each question is scored in real time.
Preconditions
The user is successfully enrolled for KBA with the Adaptive Authentication
system.
15: Knowledge-Based Authentication Workflow 65

This following image illustrates the general message flow during the KBA
authentication.
KBA System
User Browser Organizations Web Site Adaptive Authentication

3. Gather device data (IP address,

Browser information, fingerprint,
deviceTokenCookie, and
deviceTokenFSO)
4. Submit form details device data

6. Calculate the risk score

and apply policies
7. Respond with the recommended
action and available challenge methods
(In this example high risk score is generated
and the user is challenged using KBA)
8. Call Challenge with KBA ChallengeRequest

9. Pass user information to
the KBA system
10. KBA system looks up user

and sends back questions
11. Return questions and possible answers

12. Present questions to the end user
13. User picks one correct
answer for each question
14. Answers sent in Authenticate Request
:
15. Answers sent to KBA for match
16. KBA returns one of the following

responses:
-Successful Authentication
-Failed Authentication
-Additional Authentication Required
17. Authentication status sent in
Authenticate Response
18. Secure page displayed to end user
Knowledge-Based Authentication Workflow

organization.
deviceTokenFSO.
66 15: Knowledge-Based Authentication Workflow

5. The website of the organization sends the analyze request message.

The device forensic data is passed along with the user details. The analyze request
must include the device data, browser information, IP address, user name, event
type, and transaction data.
For a sample SOAP message, see Analyze SOAP Request for KBA on page 92.
6. The information in the analyze request is processed by the Risk Engine.
recommended policy action and the list of available challenge methods.
The list of challenge methods consists of the methods that the user selected during
secondary authentication. In this example, KBA is used.
For a sample SOAP message, see Analyze SOAP Response for KBA on
page 93.
8. The website sends a challenge request message to the Adaptive Authentication
system.
For a sample SOAP message, see Challenge SOAP Request for KBA on
page 94.
9. The Adaptive Authentication system passes the user information to the KBA
system.
10. The KBA system looks up the user in the records and sends back a list of
questions.
For each question, the KBA system also returns a list of possible answers. If the
user does not exist in the KBA system or if the KBA system is down, an error
message is returned.
11. The Adaptive Authentication system returns questions and possible answers to the
organization as part of a challenge response.
For a sample SOAP message, see Challenge SOAP Response for KBA on
page 95.
12. The website presents the questions and answers to the user.
13. The user picks one correct answer for each question.
14. The website sends the answers chosen by the user to the Adaptive Authentication
system as part of the authenticate request message.
For a sample SOAP message, see Authenticate SOAP Request for KBA on
page 97.
15. The Adaptive Authentication system passes the answers to the KBA system,
which checks whether the answers match.
15: Knowledge-Based Authentication Workflow 67

16. The KBA system returns one of the following responses:

If the answers match, the KBA system returns an authenticate response
indicating that the user has passed authentication successfully.
If the answers do not match, the KBA system returns an authenticate response
indicating that the user has failed authentication and the user is denied access.
If the answers match, but the KBA system determines that there is a need for
additional authentication, more questions with possible answers are returned
to the Adaptive Authentication system which, in turn, passes the questions
and answers to the website in an authenticate response.
In this case, the user must select answers for new questions, and the process to
submit the answers to the KBA system to be checked is repeated.
In this example, the user has passed authentication successfully.
17. The Adaptive Authentication system sends an authenticate response with the
authentication status.
For a sample SOAP message, see Authenticate SOAP Response for KBA
(Successful) on page 101.
68 15: Knowledge-Based Authentication Workflow

16 Out-Of-Band SMS Authentication Workflow

secondary authentication is out-of-band (OOB) SMS authentication. In OOB SMS
authentication, the RSA Adaptive Authentication (On-Premise) system sends a
one-time password through an SMS message to the user on the registered mobile
device. The user must enter the one-time password to continue the activity.
Preconditions
The user is successfully enrolled for OOB SMS with the Adaptive Authentication
system.
16: Out-Of-Band SMS Authentication Workflow 69

The following figure shows the general message flow during the OOB SMS
authentication. Each step involved in this procedure is described in the sections that
follow.

6. Calculate the
risk score and
7. Respond with the recommended action apply policies
and available challenge methods
(In this example, high risk score is generated and the user is challenged using OOB SMS )
8. Call Challenge with oobSMSChallengeRequest
9. Generate
One Time
Password
10. Send the generated One Time Password to the user through SMS

14. Validate the following:

- OTP entered matches
- OTP has not expired
- OTP is not reused
OOB SMS Authentication Workflow

organization.
deviceTokenFSO.
70 16: Out-Of-Band SMS Authentication Workflow

forensic data is passed along with the user details. The analyze request must
include the device data, browser information, IP address, user name, event type,
and transaction data.
For a sample SOAP message, see Analyze SOAP Request for OOB SMS on
page 129.
challenge methods consists of the methods that the user selected during
secondary authentication. In this example, out-of-band (OOB) SMS is used.
For a sample SOAP message, see Analyze SOAP Response for OOB SMS on
page 130.
OOB SMS.
address, sessionId, transactionId, and OOB SMS challenge data.
If you send an OOB SMS challenge request without specifying a valid contact
number, Adaptive Authentication will process the request according to the
following guidelines:
a. Retrieve the contact information by label (home, office, cellular phone, etc.).
b. Retrieve the default contact information.
c. If there is no contact information by label and no default contact information,
Adaptive Authentication will use the first contact available in the list.
Note: A valid contact number consists of phone number, area code, and country
code.
For a sample SOAP message, see Challenge SOAP Request for OOB SMS on
page 131.
9. The Adaptive Authentication system generates a one-time password for the given
For a sample SOAP message, see Challenge SOAP Response for OOB SMS on
page 132.
10. The Adaptive Authentication system creates an SMS message with the one-time
password and sends the message to the external provider, which in turn passes the
message on to the user.
12. User enters the answer and clicks the submit button.
The website must retrieve the device forensic data.
16: Out-Of-Band SMS Authentication Workflow 71

address, sessionId, transactionId, and OOB SMS data.
For a sample SOAP message, see Authenticate SOAP Request for OOB SMS
on page 133.
14. The Adaptive Authentication system validates the data entered by the user against
the generated one-time password. The Adaptive Authentication system also
validates if the one-time password has expired or is reused.
For a sample SOAP message, see Authenticate SOAP Response for OOB SMS
(Successful) on page 135.
72 16: Out-Of-Band SMS Authentication Workflow

17 One-Time Password Authentication

Workflow
prompted for secondary authentication. You can use a one-time password as part of
your implementation of a challenge method. A one-time password is not a challenge
method on its own, because you must decide how to implement and deliver the
password. You can deliver the password by phone, SMS, or email or through some
other mechanism.
In one-time password authentication, the user enrolls with an empty payload and,
during the challenge, receives a one-time password (token) in the response payload.
The user must enter the one-time password to continue the activity.
Preconditions
The user is successfully enrolled for one-time password with the RSA Adaptive
Authentication (On-Premise) system.
17: One-Time Password Authentication Workflow 73

This following figure describes the general message flow during the One-Time
Password authentication.


deviceTokenFSO)

6. Calculate the
risk score and
apply policies
and the user is challenged using OTP)
8. Call Challenge with OTP Challenge

Request
9. Generate One-Time
Password
10. Respond with the one-time password.
11. Present one-time password to user. (The organization can save the password
and present it to the user through a
medium of their choice. Sending the
password to a user browser is just one use
case.)
13. Call Authenticate to send the token

14. Verify that the
token matches the
token produced in the
Challenge flow
15. Authentication status sent in
Authenticate Response
16. Secure page is displayed to the user
One-Time Password Authentication Workflow

organization.
deviceTokenFSO.
74 17: One-Time Password Authentication Workflow

address, user name, event type, and transaction data.
For a sample SOAP message, see Analyze SOAP Request for OTP on page 138.
challenge methods consists of the methods that the user selected during
secondary authentication. In this example, one-time password is used.
For a sample SOAP message, see Analyze SOAP Response for OTP on
page 139.
8. The website of the organization sends a challenge request message to the Adaptive
For a sample SOAP message, see Challenge SOAP Request for OTP on
page 140.
9. The Adaptive Authentication system generates a one-time password.
Challenge SOAP Response for OTP on page 141
10. The Adaptive Authentication system sends the one-time password to the
organization.
11. The organization sends one-time password to the user.
The password may be delivered by phone, SMS, or email, or through some other
mechanism.
12. The user submits the one-time password.
13. The website sends the one-time password chosen by the user to the Adaptive
Authentication system as part of the authenticate request.
For a sample SOAP message, see Authenticate SOAP Request for OTP on
page 142.
14. The Adaptive Authentication system verifies that the token sent matches the token
produced in the challenge flow.
Authenticate SOAP Response for OTP (Successful) on page 144
17: One-Time Password Authentication Workflow 75

18 Failed Authentication Workflow

During user logon or transaction, if the users action is found to be risky, the user is
prompted for secondary authentication. If the user fails the authentication, the user is
challenged again, until the Maximum User Failure Count is reached. For more
information about configuring this parameter, see the section about the Administration
Console in the Operations Guide.
When the Maximum User Failure Count value is reached, the user is locked out of the
system and must be unlocked or reset by a customer service representative.
Potentially risky logons or transactions are flagged based on the action in the triggered
policies. The Flagged events are sent to the Case Management application for review
by fraud analysts. For more information, see the Back Office Users Guide.
Preconditions:
The user has an account with the website of the organization. The user is enrolled
and is verified.
18: Failed Authentication Workflow 77

The following figure shows the general message flow of a failed authentication.
Challenge questions is used as authentication method in this example. Each step
involved in this procedure is described in the sections that follow.


deviceTokenFSO)
5. Verify user credentials

score and apply
policies

and the user is challenged)
9. Call Challenge

(In this example, challenge questions are
used
12. User submits incorrect answers
14. User fails

authentication.
Failure Count
15. Respond with authentication status increases by one
(failed)
17. User submits answers
19. User Failure

Count increases
20. Respond with authentication status by one
(failed)
(If Maximum User Failure Count is
21. User cannot proceed with logon/ reached, user is locked out. If not, user
transaction is challenged again)
78 18: Failed Authentication Workflow

Failed Authentication Workflow:

1. The user requests to log on or initiate a transaction to the organizations web
application.
2. The organizations web application displays the logon or transaction page.
device data, like the IP address, Browser information, fingerprint,
During the step, the device data is sent along with the event data.
6. The organizations web application sends the analyze request message. The device
data is passed along with the user details.
For sample SOAP message, see Analyze SOAP Request for Secret Questions on
page 147.
7. The information in the analyze request is processed by the Risk Engine and a risk
score is calculated.
8. Adaptive Authentication sends an analyze response with the recommended action
and the options for secondary authentication. In this example challenge questions
are used.
Note: By default challenge questions are used as secondary authentication

method.
For sample SOAP message, see Analyze SOAP Response for Secret Questions on
page 148.
9. Send the challenge request message to retrieve information for secondary
authentication. In this example secondary authentication is done by challenge
questions.
address, sessionId, transactionId, and challenge details.
For sample SOAP message, see Challenge SOAP Request for Secret Questions on
page 149.
10. Adaptive Authentication sends a challenge response with the questions.
For sample SOAP message, see Challenge SOAP Response for Secret Questions
on page 150.
11. The organizations web application prompts the user for secondary authentication.
12. User enters incorrect answers and clicks the submit button.
Ensure to retrieve and send the device forensic data to Adaptive Authentication
system.
18: Failed Authentication Workflow 79

13. The organizations web application sends the authenticate request message. The
For sample SOAP message, see Authenticate SOAP Request for Secret Questions
on page 151.
14. User fails authentication and the failure count increases by one.
15. Adaptive Authentication sends an authenticate response message with the
authentication status. The user fails authentication.
For sample SOAP message, see Authenticate SOAP Response for Secret
Questions (Failed) on page 152.
16. The organizations web application prompts the user for secondary authentication.
17. User enters incorrect answers and clicks the submit button.
Ensure to retrieve and send the device forensic data to Adaptive Authentication
system.
18. The organizations web application sends the authenticate request message. The
For sample SOAP message, see Authenticate SOAP Request for Secret Questions
on page 151.
19. User fails authentication and the failure count increases by one.
20. Adaptive Authentication sends an authenticate response message with the
authentication status. The user fails authentication.
For sample SOAP message, see Authenticate SOAP Response for Secret
Questions (Failed) on page 152.
If the Maximum User Failure Count is reached, the user is locked out. If not, the
user is challenged again.
21. User cannot proceed with logon or transaction.
80 18: Failed Authentication Workflow

A Sample SOAP Message Flows

Allow Action Sample SOAP Message Flow
Knowledge-Based Authentication Sample SOAP Message Flow
Out-of-Band Email Sample SOAP Message Flow
Out-of-Band Phone Sample SOAP Message Flow
Out-of-Band SMS Sample SOAP Message Flow
One-Time Password Sample SOAP Message Flow
Secret Questions Sample SOAP Message Flow
Query Sample SOAP Messages
This chapter describes the sample SOAP message flows in the RSA Adaptive
Authentication (On-Premise) system.
Allow Action Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the Allow action in
the RSA Adaptive Authentication (On-Premise) system.
Create User with Binding SOAP Request for Allow Action
Create User with Binding SOAP Response for Allow Action
Analyze Session Sign in SOAP Request for Allow Action
Analyze Session Sign in SOAP Response for Allow Action
Update User with Unbinding SOAP Request for Allow Action
Update User with Unbinding SOAP Response for Allow Action
A: Sample SOAP Message Flows 81

Create User with Binding SOAP Request for Allow Action

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:genericActionTypes>SET_USER_STATUS</ws:genericActionTypes>
</ws:actionTypeList>
<ws:deviceRequest>
<ws:httpAccept>text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
</ws:httpAccept>
<ws:httpAcceptChars>ISO-8859-1,utf-8;q=0.7,*;q=0.7</ws:httpAcceptChars>
<ws:httpAcceptEncoding>gzip,deflate</ws:httpAcceptEncoding>
<ws:httpAcceptLanguage>en-us,en;q=0.5</ws:httpAcceptLanguage>
<ws:httpReferrer>http://localhost:8880/reference_application/
PreLogin.do?scenario=flow2</ws:httpReferrer>
<ws:ipAddress>72.14.207.99</ws:ipAddress>
<ws:userAgent>Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12</ws:userAgent>
</ws:deviceRequest>
<ws:identificationData>
<ws:delegated>true</ws:delegated>
<ws:userName>user</ws:userName>
<ws:userStatus>VERIFIED</ws:userStatus>
<ws:userType>PERSISTENT</ws:userType>
</ws:identificationData>
<ws:messageHeader>
<ws:apiType>DIRECT_SOAP_API</ws:apiType>
<ws:requestType>CREATEUSER</ws:requestType>
<ws:version>7.0</ws:version>
</ws:messageHeader>
<ws:securityHeader>
<ws:callerCredential>password</ws:callerCredential>
<ws:callerId>callerId</ws:callerId>
<ws:method>PASSWORD</ws:method>
</ws:securityHeader>
<ws:deviceManagementRequest>
<ws:actionTypeList>
<ws:deviceActionTypes>UPDATE_DEVICE</ws:deviceActionTypes>
<ws:deviceData>
<ws:bindingType>HARD_BIND</ws:bindingType>
<ws:newLabel>device_label</ws:newLabel>
</ws:deviceData>
</ws:deviceManagementRequest>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>
82 A: Sample SOAP Message Flows

Create User with Binding SOAP Response for Allow Action

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:createUserResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:createUserReturn xsi:type="ns1:CreateUserResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:deviceResult>
<ns1:authenticationResult>
<ns1:authStatusCode>SUCCESS</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>HARD_BIND</ns1:bindingType>
<ns1:deviceTokenCookie>PMV60200xMOiELc6%2FDJ%2BSfN69IXbfYv%2BGDF
cvOXo%2B4CJVUSHVceiZpjgC5ssPMCLmYHPzo
</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV60200xMOiELc6%2FDJ%2BSfN69IXbfYv%
2BGDFcvOXo%2B4CJVUSHVceiZpjgC5ssPMCLmYHPzo
</ns1:deviceTokenFSO>
<ns1:lookupLabel>device_label</ns1:lookupLabel>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:transactionId>0ff7-:48413be3931:83bcc554-_TRX</ns1:transactionId>
<ns1:userName>user1</ns1:userName>
<ns1:userStatus>VERIFIED</ns1:userStatus>
<ns1:userType>PERSISTENT</ns1:userType>
</ns1:identificationData>
<ns1:messageHeader>
<ns1:apiType>DIRECT_SOAP_API</ns1:apiType>
<ns1:requestType>CREATEUSER</ns1:requestType>
<ns1:timeStamp>2012-08-19T13:16:43.220Z</ns1:timeStamp>
<ns1:version>7.0</ns1:version>
</ns1:messageHeader>
<ns1:statusHeader>
<ns1:reasonCode>0</ns1:reasonCode>
<ns1:reasonDescription>Operations were completed successfully
</ns1:reasonDescription>
<ns1:statusCode>200</ns1:statusCode>
</ns1:statusHeader>
<ns1:deviceManagementResponse>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
</ns1:deviceData>
</ns1:deviceManagementResponse>
<ns1:riskResult>
<ns1:riskScore>15</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>

<ns1:actionCode>ALLOW</ns1:actionCode>
<ns1:actionName>FALLBACK RULE</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>FALLBACK RULE</ns1:ruleId>
<ns1:ruleName>FALLBACK RULE</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:createUserReturn>
</ns1:createUserResponse>
</soapenv:Body>
</soapenv:Envelope>

Analyze Session Sign in SOAP Request for Allow Action

<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:deviceTokenCookie>
PMV602T56SwvdUPv%2FzfzfKu9DmRFlftYh4GFbr%2B2WWfaiJmhxuTDHPGidD4%
2Fin4E%2FiaO%2BD</ws:deviceTokenCookie>
<ws:deviceTokenFSO>PMV602T56SwvdUPv%2FzfzfKu9DmRFlftYh4GFbr%
2B2WWfaiJmhxuTDHPGidD4%2Fin4E%2FiaO%2BD</ws:deviceTokenFSO>
<ws:httpAccept>text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
</ws:httpAccept>
<ws:httpAcceptChars>ISO-8859-1,utf-8;q=0.7,*;q=0.7
</ws:httpAcceptChars>
<ws:httpAcceptEncoding>gzip,deflate</ws:httpAcceptEncoding>
<ws:httpAcceptLanguage>en-us,en;q=0.5</ws:httpAcceptLanguage>
<ws:httpReferrer>http://localhost:8880/reference_application/
PreLogin.do?scenario=flow2</ws:httpReferrer>
<ws:userAgent>Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12</ws:userAgent>
</ws:deviceRequest>
<ws:userName>usertest1</ws:userName>
<ws:messageHeader>
<ws:requestType>ANALYZE</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:callerCredential>password1!</ws:callerCredential>
<ws:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>SESSION_SIGNIN</ws:eventType>
</ws:eventData>
</ws:eventDataList>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze Session Sign in SOAP Response for Allow Action

<soapenv:Body>
<ns1:analyzeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:analyzeReturn xsi:type="ns1:AnalyzeResponse" xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance">
<ns1:deviceResult>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:deviceTokenCookie>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9%2
B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL
<ns1:deviceTokenFSO>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fz
u9%2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL
</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:groupName/>
<ns1:transactionId>7ff7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:userName>user</ns1:userName>
<ns1:messageHeader>
<ns1:requestType>ANALYZE</ns1:requestType>
<ns1:statusHeader>
<ns1:reasonDescription>Operations were completed
successfully</ns1:reasonDescription>
</ns1:statusHeader>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>userBoundLowRisk</ns1:actionName>
<ns1:ruleId>userBoundLowRisk</ns1:ruleId>
<ns1:ruleName>userBoundLowRisk</ns1:ruleName>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

Update User with Unbinding SOAP Request for Allow Action

<soapenv:Header/>
<soapenv:Body>
<ws:updateUser>
<ws:request>
<ws:deviceRequest>
<ws:deviceTokenCookie>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9%
2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL</ws:deviceTokenCookie>
<ws:deviceTokenFSO>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9
%2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL</ws:deviceTokenFSO>
</ws:deviceRequest>
<ws:messageHeader>
<ws:requestType>UPDATEUSER</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:deviceManagementRequest>
<ws:actionTypeList>
<ws:deviceActionTypes>UPDATE_DEVICE</ws:deviceActionTypes>
<ws:deviceData>
<ws:bindingType>NONE</ws:bindingType>
<ws:lookupLabel>device_label</ws:lookupLabel>
</ws:deviceData>
</ws:deviceManagementRequest>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

Update User with Unbinding SOAP Response for Allow Action

<soapenv:Body>
<ns1:updateUserResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:updateUserReturn xsi:type="ns1:UpdateUserResponse"
<ns1:deviceResult>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<ns1:deviceTokenCookie>PMV602ood%2FywfHej3XxD3OGAA7sXC0vOqWr2ej6
%2BPFl6WgxwsML1O0wUhS80WEsEJ1htMd</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV602ood%2FywfHej3XxD3OGAA7sXC0vOqWr2ej6
%2BPFl6WgxwsML1O0wUhS80WEsEJ1htMd</ns1:deviceTokenFSO>
<ns1:lookupLabel>No Label</ns1:lookupLabel>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>4ff7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:requestType>UPDATEUSER</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:deviceManagementResponse>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
</ns1:deviceData>
</ns1:deviceManagementResponse>
<ns1:riskResult>
<ns1:triggeredRule>

</ns1:riskResult>
</ns1:updateUserReturn>
</ns1:updateUserResponse>
</soapenv:Body>
</soapenv:Envelope>
Knowledge-Based Authentication Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the
Knowledge-Based Authentication (KBA) authentication method.
Create User SOAP Request for KBA
Create User SOAP Response for KBA
Analyze SOAP Request for KBA
Analyze SOAP Response for KBA
Challenge SOAP Request for KBA
Challenge SOAP Response for KBA
Authenticate SOAP Request for KBA
Authenticate SOAP Response for KBA (Failed)
Authenticate SOAP Response for KBA (Pending)
Authenticate SOAP Response for KBA (Successful)

Create User SOAP Request for KBA

<soapenv:Body>
<ws:createUser xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:actionTypeList>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:credentialManagementRequestList>
<ws:acspManagementRequestData>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload xsi:type="ns401:KBAManagementRequest"
xmlns:ns401="http://ws.kba.csd.rsa.com"
<ns401:action>ADD</ns401:action>
<ns401:personInfo>
<ns401:ssnInfo>
<ns401:ssnType>NOSSN</ns401:ssnType>
</ns401:ssnInfo>
<ns401:nameInfo>
<ns401:firstName>****</ns401:firstName>
<ns401:lastName>******</ns401:lastName>
</ns401:nameInfo>
<ns401:addressInfo>
<ns401:street>*************</ns401:street>
<ns401:town>******</ns401:town>
<ns401:postCode>******</ns401:postCode>
</ns401:addressInfo>
<ns401:birthdayInfo>
<ns401:day>**</ns401:day>
<ns401:month>**</ns401:month>
<ns401:year>****</ns401:year>
</ns401:birthdayInfo>
</ns401:personInfo>
</ws:payload>
</ws:acspManagementRequestData>
</ws:credentialManagementRequestList>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for KBA

<ns1:transactionId>e966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:acspManagementResponseData>
<ns1:callStatus>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAManagementResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com">
<ns2:personInfo>
<ns2:ssnInfo>
</ns2:ssnInfo>
<ns2:nameInfo>
<ns2:lastName>*******</ns2:lastName>
</ns2:nameInfo>
<ns2:addressInfo>
<ns2:street>************</ns2:street>
<ns2:town>******</ns2:town>
<ns2:postCode>*******</ns2:postCode>
</ns2:addressInfo>
<ns2:birthdayInfo>
</ns2:birthdayInfo>
</ns2:personInfo>
</ns1:payload>
</ns1:acspManagementResponseData>
</ns1:credentialManagementResponseList>
<ns1:riskResult>

<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>
Analyze SOAP Request for KBA

The following sample displays a SOAP message for the Session Sign in event type.
<soapenv:Body>
<ws:analyze xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for KBA

The following sample displays a SOAP message for the Session Sign in event type.
<soapenv:Body>
<ns1:analyzeReturn xsi:type="ns1:AnalyzeResponse"
<ns1:sessionId>4bccc90a:1396541c967:-669b</ns1:sessionId>
<ns1:transactionId>a966-:769c1456931:a09cccb4_TRX
</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>USER_DEFINED</ns1:credentialType>
<ns1:genericCredentialType>KBA</ns1:genericCredentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>AuthDevNotBound</ns1:actionName>
<ns1:ruleId>AuthDevNotBound</ns1:ruleId>
<ns1:ruleName>AuthDevNotBound</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for KBA

<soapenv:Body>
<ws:challenge xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:sessionId>4bccc90a:1396541c967:-669b</ws:sessionId>
<ws:transactionId>a966-:769c1456931:a09cccb4_TRX
</ws:transactionId>
<ws:messageHeader>
<ws:requestType>CHALLENGE</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:credentialChallengeRequestList>
<ws:acspChallengeRequestData>
<ws:payload xsi:type="ns753:KBAChallengeRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</ws:acspChallengeRequestData>
</ws:credentialChallengeRequestList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for KBA

<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
<ns1:transactionId>a966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:requestType>CHALLENGE</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:acspChallengeResponseData>
<ns1:callStatus>
<ns1:statusDescription>Questions and answers retrieved
successfully from KBA</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAChallengeResponse"
<ns2:questions>
<ns2:questionId>8022125922658</ns2:questionId>
<ns2:text>Which of the following people have you
known?</ns2:text>
<ns2:choices>
<ns2:choiceId>8026835568776</ns2:choiceId>
<ns2:text>Arthur Matt</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Eamon Johnson</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Eileen Prestwood</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Neil Owen</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Sheena Ishmail</ns2:text>
</ns2:choices>
<ns2:choices>

<ns2:text>None of the above</ns2:text>

</ns2:choices>
</ns2:questions>
<ns2:questions>
<ns2:text>In which of the following districts or locations
have you ever lived?</ns2:text>
<ns2:choices>
<ns2:text>Cefn Cribwr</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Dyce</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Norbury</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Send</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Twyford</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>I have never lived or owned property in any of
these districts</ns2:text>
</ns2:choices>
</ns2:questions>
<ns2:questions><ns2:questionId>8022125922660</ns2:questionId>
<ns2:text>What month was 'Lesley Sweeney' born in?</ns2:text>
<ns2:choices>
<ns2:text>January</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>March</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>May</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>August</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>October</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Either 1) none of the above; or 2) I am not
familiar with this person.</ns2:text>
</ns2:choices>
</ns2:questions>
</ns1:payload>
</ns1:acspChallengeResponseData>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Request for KBA

<soapenv:Body>
<ws:authenticate xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:sessionId>4bccc90a:1396541c967:-669b</ws:sessionId>
<ws:transactionId>a966-:769c1456931:a09cccb4_TRX
</ws:transactionId>
<ws:messageHeader>
<ws:requestType>AUTHENTICATE</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:credentialDataList>
<ws:acspAuthenticationRequestData>
<ws:payload xsi:type="ns977:KBAAuthenticationRequest"
<ns977:answers>
<ns977:choiceIds>8026835568781</ns977:choiceIds>
</ns977:answers>
<ns977:answers>
</ns977:answers>
<ns977:answers>
</ns977:answers>
</ws:payload>
</ws:acspAuthenticationRequestData>
</ws:credentialDataList>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for KBA (Failed)

The following example shows a failed Authenticate SOAP Response for KBA. The
end user answered one question correctly and fails KBA authentication.
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
<ns1:sessionId>4bccc90a:1396541c967:-6671</ns1:sessionId>
<ns1:transactionId>0766-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:requestType>AUTHENTICATE</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:callStatus>
<ns1:statusCode>FAIL</ns1:statusCode>
<ns1:statusDescription>Failed: iAuth Questions; Frequency
violation information:</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAAuthenticationResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com"/>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for KBA (Pending)

The following example shows a pending Authenticate response for Knowledge-Based
Authentication. The end user answered two answers correctly and will receive an
additional question to confirm authentication.
<soapenv:Body>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialAuthResultListxsi:type="ns1:CredentialAuthResultList">
<ns1:callStatus>
<ns1:statusCode>PENDING</ns1:statusCode>
<ns1:statusDescription>Additional questions and answers
have been retrieved successfully
from KBA</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAAuthenticationResponse"
<ns2:questions>
<ns2:text>In which of the following districts or
locations have you ever lived?</ns2:text>
<ns2:choices>
<ns2:text>Colden Common</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Coleford</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Finsbury Park</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>Lochee</ns2:text>
</ns2:choices>

<ns2:choices>
<ns2:text>Pill</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:text>I have never lived or owned property
in any of these districts</ns2:text>
</ns2:choices>
</ns2:questions>
</ns1:payload>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for KBA (Successful)

The following example shows a successful Authenticate response for
Knowledge-Based Authentication. The end user answered all questions correctly.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialAuthResultListxsi:type=
"ns1:CredentialAuthResultList">
<ns1:callStatus>
<ns1:statusDescription>Answers match in
KBA</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload
xsi:type="ns2:KBAAuthenticationResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com"/>
</soapenv:Body>
</soapenv:Envelope>

Out-of-Band Email Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the out-of band
(OOB) email authentication method.
Create User SOAP Request for OOB Email
Create User SOAP Response for OOB Email
Update User SOAP Request for OOB Email
Update User SOAP Response for OOB Email
Analyze SOAP Request for OOB Email
Analyze SOAP Response for OOB Email
Challenge SOAP Request for OOB Email
Challenge SOAP Response for OOB Email
Authenticate SOAP Request for OOB Email
Authenticate SOAP Response for OOB Email (Failed)
Authenticate SOAP Response for OOB Email (Success)

Create User SOAP Request for OOB Email

<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:userName>user10</ws:userName>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:oobEmailManagementRequest>
<ws:payload>
<ws:oobActionTypeList>
<ws:oobActionType>ADD_OOB</ws:oobActionType>
</ws:oobActionTypeList>
<ws:contactList>
<ws:defaultFlag>true</ws:defaultFlag>
<ws:label>contact_list_label</ws:label>
<ws:address>address@rsa.com</ws:address>
</ws:contactList>
</ws:payload>
</ws:oobEmailManagementRequest>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for OOB Email

<soapenv:Body>
<ns1:transactionId>fff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobEmailManagementResponse>
<ns1:payload xsi:type="ns1:EmailManagementResponsePayload">
<ns1:acspAccountId>user10</ns1:acspAccountId>
<ns1:callStatus>
</ns1:callStatus>
<ns1:contactList xsi:type="ns1:EmailInfo">
<ns1:defaultFlag>true</ns1:defaultFlag>
<ns1:label>contact_list_label</ns1:label>
<ns1:lastModified>2012-08-20T10:43:45.810+03:00
</ns1:lastModified>
<ns1:reference>0</ns1:reference>
<ns1:address>address@rsa.com</ns1:address>
</ns1:contactList>
</ns1:payload>
</ns1:oobEmailManagementResponse>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Update User SOAP Request for OOB Email

<soapenv:Header/>
<soapenv:Body>
<ws:updateUser>
<ws:request>
<ws:actionTypeList>
<ws:genericActionTypes>SET_PHRASE</ws:genericActionTypes>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

Update User SOAP Response for OOB Email

<soapenv:Body>
<ns1:groupName/>
<ns1:transactionId>dff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Request for OOB Email

The following sample displays a SOAP message for the Payment event type.
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
</ws:deviceRequest>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>PAYMENT</ws:eventType>
<ws:transactionData>
<ws:amount>
<ws:amount>1000000</ws:amount>
<ws:amountInUSD>1000000</ws:amountInUSD>
<ws:currency>USD</ws:currency>
</ws:amount>
<ws:executionSpeed>REAL_TIME</ws:executionSpeed>
<ws:otherAccountBankType>OTHER_BANK</ws:otherAccountBankType>
<ws:otherAccountData>
<ws:accountName>otherAccountName</ws:accountName>
<ws:accountNumber>123456789</ws:accountNumber>
</ws:otherAccountData>
<ws:otherAccountOwnershipType>ME_TO_YOU
</ws:otherAccountOwnershipType>
<ws:otherAccountType>PERSONAL_ACCOUNT</ws:otherAccountType>
</ws:transactionData>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for OOB Email

The following sample displays a SOAP message for the Payment event type.
<soapenv:Body>
<ns1:deviceResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:deviceTokenCookie>PMV602EbovpQBP4%2FXLTti6rJNqjrcXjQOFhN
%2B4okMH7zrAZ6i1ewPbOmeqXWhMMT%2BGCZMS
<ns1:deviceTokenFSO>PMV602EbovpQBP4%2FXLTti6rJNqjrcXjQOFhN%
2B4okMH7zrAZ6i1ewPbOmeqXWhMMT%2BGCZMS</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:groupName/>
<ns1:sessionId>-59685e99:13942fcc431:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialType>OOBEMAIL</ns1:credentialType>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>IPOnWatchList</ns1:actionName>
<ns1:ruleId>IPOnWatchList</ns1:ruleId>
<ns1:ruleName>IPOnWatchList</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for OOB Email

<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:sessionId>-59685e99:13942fcc431:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:oobEmailChallengeRequest>
<ws:payload>
<ws:emailInfo>
<ws:label>email_label</ws:label>
<ws:address>address@rsa.com</ws:address>
</ws:emailInfo>
<ws:fromAddress>from.address@rsa.com</ws:fromAddress>
<ws:fromName>from name</ws:fromName>
<ws:noOp>false</ws:noOp>
<ws:subject>email_subject</ws:subject>
</ws:payload>
</ws:oobEmailChallengeRequest>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for OOB Email

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobEmailChallenge>
<ns1:payload>
<ns1:authStatusCode>PENDING</ns1:authStatusCode>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CREATED</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
</ns1:payload>
</ns1:oobEmailChallenge>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Request for OOB Email

<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:sessionId>-59685e99:13942fcc431:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:oobEmailData>
<ws:payload>
<ws:token>615951</ws:token>
</ws:payload>
</ws:oobEmailData>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OOB Email (Failed)

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobEmailAuthResult>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_FAILED</ns1:channelStatus>
</ns1:payload>
</ns1:oobEmailAuthResult>
<ns1:credentialType>OOBEMAIL</ns1:credentialType>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OOB Email (Success)

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobEmailAuthResult>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_SUCCESS</ns1:channelStatus>
</ns1:payload>
</ns1:oobEmailAuthResult>
</soapenv:Body>
</soapenv:Envelope>

Out-of-Band Phone Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the out-of-band
(OOB) phone authentication method.
Create User SOAP Request for OOB Phone
Create User SOAP Response for OOB Phone
Analyze SOAP Request for OOB Phone
Analyze SOAP Response for OOB Phone
Challenge SOAP Request for OOB Phone
Challenge SOAP Response for OOB Phone
Query Authentication Status SOAP Request for OOB Phone
Query Authentication Status SOAP Response for OOB Phone (Failed)
Query Authentication Status SOAP Response for OOB Phone (Success)

Create User SOAP Request for OOB Phone

<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:orgName>org</ws:orgName>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:oobPhoneManagementRequest>
<ws:payload>
<ws:oobActionTypeList>
<ws:oobActionType>ADD_OOB</ws:oobActionType>
</ws:oobActionTypeList>
<ws:contactList>
<ws:label>work</ws:label>
<ws:areaCode>972</ws:areaCode>
<ws:countryCode>074</ws:countryCode>
<ws:phoneNumber>7380000</ws:phoneNumber>
</ws:contactList>
</ws:payload>
</ws:oobPhoneManagementRequest>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for OOB Phone

<soapenv:Body>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>fff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobPhoneManagementResponse>
<ns1:payload xsi:type="ns1:PhoneManagementResponsePayload">
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
</ns1:callStatus>
<ns1:contactList xsi:type="ns1:PhoneInfo">
<ns1:defaultFlag>true</ns1:defaultFlag>
<ns1:label>work</ns1:label>
<ns1:lastModified>2012-08-22T11:44:00.614+03:00
</ns1:lastModified>
<ns1:reference>0</ns1:reference>
<ns1:areaCode>972</ns1:areaCode>
<ns1:countryCode>074</ns1:countryCode>
<ns1:extension/>
<ns1:phoneNumber>7380000</ns1:phoneNumber>
</ns1:contactList>
</ns1:payload>
</ns1:oobPhoneManagementResponse>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Request for OOB Phone

The following sample displays a SOAP message for the Add Payee event type.
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
</ws:deviceRequest>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ADD_PAYEE</ws:eventType>
<ws:otherAccountBankType>SAME_BANK</ws:otherAccountBankType>
<ws:otherAccountData>
<ws:accountOwnershipType>BUSINESS</ws:accountOwnershipType>
</ws:otherAccountData>
<ws:otherAccountOwnershipType>ME_TO_YOU
</ws:otherAccountOwnershipType>
<ws:otherAccountType>BILLER</ws:otherAccountType>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for OOB Phone

The following sample displays a SOAP message for the Add Payee event type.
<soapenv:Body>
<ns1:deviceResult>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:deviceTokenCookie>PMV600EZq5vSB%2BJFjaGcTNuwlhcQw%2FXKKgmZtT
G1bMZ1AGuEOFJKThgc3cD%2FEYBZJhNQ9g</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV600EZq5vSB%2BJFjaGcTNuwlhcQw%2FXKKgmZtTG
1bMZ1AGuEOFJKThgc3cD%2FEYBZJhNQ9g</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:groupName/>
<ns1:sessionId>-7b3a725d:1394d80a375:-7ffe</ns1:sessionId>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialType>OOBPHONE</ns1:credentialType>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>CountryOnWatchList</ns1:actionName>
<ns1:ruleId>CountryOnWatchList</ns1:ruleId>
<ns1:ruleName>CountryOnWatchList</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for OOB Phone

<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:sessionId>-7b3a725d:1394d80a375:-7ffe</ws:sessionId>
<ws:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:oobPhoneChallengeRequest>
<ws:payload>
<ws:noOp>false</ws:noOp>
<ws:phoneInfo>
<ws:label>work</ws:label>
</ws:phoneInfo>
<ws:tokenCollectionFlow>true</ws:tokenCollectionFlow>
</ws:payload>
</ws:oobPhoneChallengeRequest>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ADD_PAYEE</ws:eventType>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for OOB Phone

<soapenv:Body>
<ns1:groupName/>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:oobPhoneChallenge>
<ns1:payload>
<ns1:authStatusCode>PENDING</ns1:authStatusCode>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CREATED</ns1:channelStatus>
<ns1:token>042985</ns1:token>
</ns1:payload>
</ns1:oobPhoneChallenge>
</soapenv:Body>
</soapenv:Envelope>

Query Authentication Status SOAP Request for OOB Phone

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
<soapenv:Header/>
<soapenv:Body>
<ws:queryAuthStatus>
<ws:request>
<ws:sessionId>-7b3a725d:1394d80a375:-7ffe</ws:sessionId>
<ws:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
</ws:transactionId>
<ws:messageHeader>
<ws:requestType>QUERYAUTHSTATUS</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:credentialAuthStatusRequest>
<ws:oobPhoneAuthStatusRequest>
<ws:payload>
<ws:token>042985</ws:token>
</ws:payload>
</ws:oobPhoneAuthStatusRequest>
</ws:credentialAuthStatusRequest>
</ws:request>
</ws:queryAuthStatus>
</soapenv:Body>
</soapenv:Envelope>

Query Authentication Status SOAP Response for OOB Phone (Failed)

<soapenv:Body>
<ns1:queryAuthStatusResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:queryAuthStatusReturn xsi:type="ns1:QueryAuthStatusResponse"
<ns1:groupName/>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:requestType>QUERYAUTHSTATUS</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialAuthStatusResponse
xsi:type="ns1:CredentialAuthStatusResponse">
<ns1:oobPhoneAuthStatusResponse>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_FAILED</ns1:channelStatus>
<ns1:reason>Reason.CONFIRMATION_NUM_FAILURE</ns1:reason>
</ns1:payload>
</ns1:oobPhoneAuthStatusResponse>
</ns1:credentialAuthStatusResponse>
</ns1:queryAuthStatusReturn>
</ns1:queryAuthStatusResponse>
</soapenv:Body>
</soapenv:Envelope>

Query Authentication Status SOAP Response for OOB Phone (Success)

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:queryAuthStatusResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:queryAuthStatusReturn xsi:type="ns1:QueryAuthStatusResponse"
<ns1:groupName/>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
<ns1:messageHeader>
<ns1:requestType>QUERYAUTHSTATUS</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialAuthStatusResponse
xsi:type="ns1:CredentialAuthStatusResponse">
<ns1:oobPhoneAuthStatusResponse>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_SUCCESS
</ns1:channelStatus>
</ns1:payload>
</ns1:oobPhoneAuthStatusResponse>
</ns1:credentialAuthStatusResponse>
</ns1:queryAuthStatusReturn>
</ns1:queryAuthStatusResponse>
</soapenv:Body>
</soapenv:Envelope>

Out-of-Band SMS Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the out-of-band
(OOB) SMS authentication method.
Create User SOAP Request for OOB SMS
Create User SOAP Response for OOB SMS
Update User SOAP Request for OOB SMS
Update User SOAP Response for OOB SMS
Analyze SOAP Request for OOB SMS
Analyze SOAP Response for OOB SMS
Challenge SOAP Request for OOB SMS
Challenge SOAP Response for OOB SMS
Authenticate SOAP Request for OOB SMS
Authenticate SOAP Response for OOB SMS (Failed)
Authenticate SOAP Response for OOB SMS (Successful)

Create User SOAP Request for OOB SMS

<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:groupName>group</ws:groupName>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for OOB SMS

<soapenv:Body>
<ns1:transactionId>fff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Update User SOAP Request for OOB SMS

<soapenv:Header/>
<soapenv:Body>
<ws:updateUser>
<ws:request>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ns934:OOBSMSManagementRequest"
xmlns:ns934="http://ws.oobsms.csd.rsa.com"
<ws1:action xmlns:ws1="http://ws.oobgen.csd.rsa.com">ADD
</ws1:action>
<ws1:contactList xmlns:ws1="http://ws.oobgen.csd.rsa.com">
<ws1:isDefault>true</ws1:isDefault>
<ws1:phoneNumber>2500000</ws1:phoneNumber>
<ws1:countryCode>972</ws1:countryCode>
<ws1:areaCode>54</ws1:areaCode>
<ws1:label>my mobile</ws1:label>
</ws1:contactList>
</ws:payload>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

Update User SOAP Response for OOB SMS

<soapenv:Body>
<ns1:groupName/>
<ns1:transactionId>dff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSManagementResponse"
xmlns:ns3="http://ws.oobsms.csd.rsa.com">
<ns2:action
xmlns:ns2="http://ws.oobgen.csd.rsa.com">ADD</ns2:action>
<contactList xmlns="http://ws.oobgen.csd.rsa.com">
<isDefault>true</isDefault>
<phoneNumber>2500000</phoneNumber>
<countryCode>972</countryCode>
<areaCode>54</areaCode>
<label>my mobile</label>
</contactList>
</ns1:payload>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Request for OOB SMS

The following sample displays a SOAP message for the Active Card event type.
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
</ws:deviceRequest>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ACTIVATE_CARD</ws:eventType>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for OOB SMS

The following sample displays a SOAP message for the Active Card event type.
<soapenv:Body>
<ns1:deviceResult>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:deviceTokenCookie>PMV600257TFD4qBojEz4ROsjx%2F%2BwfwN9iErI
Ye5bLsuYRFLTU3Ot9Ff7%2FTeu7XTfi%2FEmNi</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV600257TFD4qBojEz4ROsjx%2F%2BwfwN9iErIYe5bLs
uYRFLTU3Ot9Ff7%2FTeu7XTfi%2FEmNi</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:groupName/>
<ns1:sessionId>4ff806f:1394f372a0e:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:genericCredentialType>OOBSMS</ns1:genericCredentialType>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>CountryOnWatchList</ns1:actionName>
<ns1:ruleId>CountryOnWatchList</ns1:ruleId>
<ns1:ruleName>CountryOnWatchList</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for OOB SMS

<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:sessionId>4ff806f:1394f372a0e:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ns157:OOBSMSChallengeRequest"
<ws:contactList xmlns:ws="http://ws.oobgen.csd.rsa.com">
<ws:isDefault>true</ws:isDefault>
<ws:label>my mobile</ws:label>
</ws:contactList>
</ws:payload>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for OOB SMS

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusCode>PENDING</ns1:statusCode>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSChallengeResponse"
xmlns:ns3="http://ws.oobsms.csd.rsa.com"/>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Request for OOB SMS

<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:sessionId>4ff806f:1394f372a0e:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ns417:OOBSMSAuthenticationRequest"
<ws:otp xmlns:ws="http://ws.oobsms.csd.rsa.com">0nbf7X</ws:otp>
</ws:payload>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OOB SMS (Failed)

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusDescription>OTP doesn't match</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSAuthenticationResponse"
<ns1:genericCredentialType>OOBSMS</ns1:genericCredentialType>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OOB SMS (Successful)

<soapenv:Body>
<ns1:groupName/>
<ns1:userStatus>LOCKOUT</ns1:userStatus>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusDescription>OTP matches</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSAuthenticationResponse"
</soapenv:Body>
</soapenv:Envelope>
One-Time Password Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the one-time
password (OTP) authentication method.
Create User SOAP Request for OTP
Create User SOAP Response for OTP
Analyze SOAP Request for OTP
Analyze SOAP Response for OTP
Challenge SOAP Request for OTP
Challenge SOAP Response for OTP
Authenticate SOAP Request for OTP

Authenticate SOAP Response for OTP (Failed)

Authenticate SOAP Response for OTP (Successful)
Create User SOAP Request for OTP

<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ws:OTPManagementRequest"
<ws:opcode/>
</ws:payload>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for OTP

<soapenv:Body>
<ns1:transactionId>9df7-:3f8d0be4931:d36fd4e7_TRX
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPManagementResponse"/>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Request for OTP

The following sample displays a SOAP message for the Request Credit event type.
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>REQUEST_CREDIT</ws:eventType>
<ws:myAccountData>
<ws:accountName>accountName</ws:accountName>
<ws:internationalAccountNumber>123456
</ws:internationalAccountNumber>
<ws:accountOwnershipType>INDIVIDUAL
</ws:accountOwnershipType>
</ws:myAccountData>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for OTP

The following sample displays a SOAP message for the Request Credit event type.
<soapenv:Body>
<ns1:groupName/>
<ns1:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ns1:sessionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:genericCredentialType>OTP</ns1:genericCredentialType>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>HighEfnScore</ns1:actionName>
<ns1:ruleId>HighEfnScore</ns1:ruleId>
<ns1:ruleName>HighEfnScore</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for OTP

<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ws:sessionId>
<ws:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ws:OTPChallengeRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for OTP

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusDescription>OTP allocated</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPChallengeResponse">
<ns1:otp>742705</ns1:otp>
</ns1:payload>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Request for OTP

<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ws:sessionId>
<ws:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ws:transactionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ws:OTPAuthenticationRequest"
<ws:otp>742705</ws:otp>
</ws:payload>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OTP (Failed)

<soapenv:Body>
<ns1:groupName/>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusDescription>OTP doesn't
match</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPAuthenticationResponse"/>
<ns1:genericCredentialType>OTP</ns1:genericCredentialType>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for OTP (Successful)

<soapenv:Body>
<ns1:groupName/>
<ns1:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
<ns1:statusDescription>OTP matches</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPAuthenticationResponse"/>
</soapenv:Body>
</soapenv:Envelope>
Secret Questions Sample SOAP Message Flow

The following SOAP messages outline a sample message flow for the Secret
Questions authentication method.
Create User SOAP Request for Secret Questions
Create User SOAP Response for Secret Questions
Analyze SOAP Request for Secret Questions
Analyze SOAP Response for Secret Questions
Challenge SOAP Request for Secret Questions
Challenge SOAP Response for Secret Questions
Authenticate SOAP Request for Secret Questions
Authenticate SOAP Response for Secret Questions (Failed)
Authenticate SOAP Response for Secret Questions (Successful)

Create User SOAP Request for Secret Questions

<soapenv:Header/>
<soapenv:Body>
<ws:createUser>
<ws:request>
<ws:actionTypeList>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:challengeQuestionManagementRequest>
<ws:payload>
<ws:actionTypeList>
<ws:challengeQuestionActionType>SET_USER_QUESTION
</ws:challengeQuestionActionType>
<ws:challengeQuestionConfig>
<ws:excludeUserQuestions>false</ws:excludeUserQuestions>
<ws:includeRetired>false</ws:includeRetired>
</ws:challengeQuestionConfig>
<ws:challengeQuestionList>
<ws:challengeQuestion>
<ws:actualAnswer>answer</ws:actualAnswer>
<ws:questionId>Q1.1</ws:questionId>
</ws:challengeQuestion>
</ws:challengeQuestionList>
</ws:payload>
</ws:challengeQuestionManagementRequest>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

Create User SOAP Response for Secret Questions

<soapenv:Body>
<ns1:transactionId>5df7-:c77173f3931:78c359c7_TRX
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:challengeQuestionManagementResponse>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
</ns1:payload>
</ns1:challengeQuestionManagementResponse>
<ns1:riskResult>
<ns1:triggeredRule>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Request for Secret Questions

The following sample displays a SOAP message for the Session sign in event type.
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:devicePrint><![CDATA[version=&pm_fpua=mozilla/4.0
(compatible; msie 6.0; windows nt 5.1; sv1; .net clr 1.1.4322;
infopath.1)|4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
CLR 1.1.4322; InfoPath.1)|Win32|;SP2;|x86|en-us| 8831&
pm_fpsc=32|1280|1024|996&pm_fpsw=abk=6,0,2600,0|
wnt=6,0,2900,2180|dht=5,5000,3130,0|dhj=6,0,1,223|
dan=6,0,3,531|dsh=10,0,0,3646|ie5=6,0,2900,2180|
icw=5,0,2918,1900|ieh=6,0,2900,2180|iee=4,74,9273,0|
wmp=10,0,0,3646|obp=6,0,2900,2180|oex=6,0,2900,2180|
net=4,4,0,3400|tks=4,71,1968,1|mvm=5,0,3805,0&
pm_fptz=-7&pm_fpln=lang=en-us|syslang=en-us|
userlang=en-us&pm_fpjv=1&pm_fpco=1]]>
</ws:devicePrint>
</ws:deviceRequest>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:eventDataList>
<ws:eventData>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

Analyze SOAP Response for Secret Questions

The following sample displays a SOAP message for the Session sign in event type.
<soapenv:Body>
<ns1:deviceResult>
<ns1:callStatus>
</ns1:callStatus>
<ns1:deviceData>
<ns1:deviceTokenCookie>PMV602kFUUIt2OSwKe6VUKh2suovadSSIg%
2BROPI5Xxuf2TxDj2Q3E2yKFlrcu8SM7FbtF7</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV602kFUUIt2OSwKe6VUKh2suovadSSIg%
2BROPI5Xxuf2TxDj2Q3E2yKFlrcu8SM7FbtF7</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:groupName/>
<ns1:sessionId>7c953c87:1393f37177c:-7fd4</ns1:sessionId>
<ns1:transactionId>3df7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:credentialType>QUESTION</ns1:credentialType>
<ns1:riskResult>
<ns1:triggeredRule>
<ns1:actionName>AuthDevNotBound</ns1:actionName>
<ns1:ruleId>AuthDevNotBound</ns1:ruleId>
<ns1:ruleName>AuthDevNotBound</ns1:ruleName>
</ns1:riskResult>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Request for Secret Questions

<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:sessionId>7c953c87:1393f37177c:-7fdb</ws:sessionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:challengeQuestionChallengeRequest>
<ws:payload>
<ws:numberOfQuestion>1</ws:numberOfQuestion>
</ws:payload>
</ws:challengeQuestionChallengeRequest>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

Challenge SOAP Response for Secret Questions

<soapenv:Body>
<ns1:groupName/>
<ns1:sessionId>7c953c87:1393f37177c:-7fdb</ns1:sessionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:challengeQuestionChallenge>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:challengeQuestions>
<ns1:challengeQuestion>
<ns1:questionId>Q1.1</ns1:questionId>
<ns1:questionText>In what city was your high school? (full
name of city only)</ns1:questionText>
</ns1:challengeQuestion>
</ns1:challengeQuestions>
</ns1:payload>
</ns1:challengeQuestionChallenge>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Request for Secret Questions

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:sessionId>7c953c87:1393f37177c:-7fdb</ws:sessionId>
<ws:messageHeader>
</ws:messageHeader>
<ws:securityHeader>
<ws:challengeQuestionData>
<ws:payload>
<ws:challengeQuestion>
<ws:questionId>Q1.1</ws:questionId>
<ws:userAnswer>answer/wrong answer</ws:userAnswer>
</ws:challengeQuestion>
</ws:payload>
</ws:challengeQuestionData>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for Secret Questions (Failed)

<soapenv:Body>
<ns1:groupName/>
<ns1:sessionId>7c953c87:1393f37177c:-7fd4</ns1:sessionId>
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:challengeQuestionAuthResult>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:challengeQuestionMatchResult>
<ns1:failCount>1</ns1:failCount>
<ns1:matchCount>0</ns1:matchCount>
</ns1:challengeQuestionMatchResult>
</ns1:payload>
</ns1:challengeQuestionAuthResult>
<ns1:credentialType>QUESTION</ns1:credentialType>
</soapenv:Body>
</soapenv:Envelope>

Authenticate SOAP Response for Secret Questions (Successful)

<soapenv:Body>
<ns1:groupName/>
<ns1:transactionId>bcf7-:c77173f3931:78c359c7_TRX
<ns1:messageHeader>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:challengeQuestionAuthResult>
<ns1:payload>
<ns1:callStatus>
</ns1:callStatus>
<ns1:challengeQuestionMatchResult>
<ns1:failCount>0</ns1:failCount>
<ns1:matchCount>1</ns1:matchCount>
</ns1:challengeQuestionMatchResult>
</ns1:payload>
</ns1:challengeQuestionAuthResult>
</soapenv:Body>
</soapenv:Envelope>

Query Sample SOAP Messages

The following SOAP messages outline a sample message flow for the Query SOAP
call in the Adaptive Authentication system.
Query SOAP Request for KBA
Note: The following SOAP message sample uses the KBA authentication method.
<soapenv:Body>
<ws:query xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:messageHeader>
<ws:requestType>QUERY</ws:requestType>
</ws:messageHeader>
<ws:securityHeader>
<ws:payload xsi:type="ns425:KBAManagementRequest"
<ns425:action>GET</ns425:action>
</ws:payload>
</ws:request>
</ws:query>
</soapenv:Body>
</soapenv:Envelope>

Query SOAP Response for KBA
Note: The following SOAP message sample uses the KBA authentication method.
<soapenv:Body>
<ns1:queryResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:queryReturn xsi:type="ns1:QueryResponse"
<ns1:transactionId>c966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:messageHeader>
<ns1:requestType>QUERY</ns1:requestType>
<ns1:statusHeader>
</ns1:statusHeader>
<ns1:callStatus>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAManagementResponse"
<ns2:personInfo>
<ns2:ssnInfo>
</ns2:ssnInfo>
<ns2:nameInfo>
<ns2:lastName>*******</ns2:lastName>
</ns2:nameInfo>
<ns2:addressInfo>
<ns2:street>**************</ns2:street>
<ns2:town>*******</ns2:town>
<ns2:postCode>*******</ns2:postCode>
</ns2:addressInfo>
<ns2:birthdayInfo>
</ns2:birthdayInfo>
</ns2:personInfo>
</ns1:payload>
</ns1:queryReturn>
</ns1:queryResponse>
</soapenv:Body>
</soapenv:Envelope>

WorkflowsProcesses Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

WorkflowsProcesses Guide

Enviado por

Direitos autorais:

Formatos disponíveis

RSA Adaptive Authentication

About This Guide

RSA Adaptive Authentication (On-Premise) Documentation

Support and Service

Customer Support Information www.emc.com/support/rsa/index.htm

RSA Solution Gallery https://gallery.emc.com/community/marketplace/rsa?

RSA SecurCare Online offers a knowledgebase that contains answers to common

Before You Call Customer Support

Chapter 1: Understanding the Workflows ....................................................... 9

Chapter 2: Authentication Workflow ................................................................ 13

Chapter 4: Transaction Authentication Workflow .................................... 19

Chapter 5: Enrollment Workflow ......................................................................... 23

Chapter 8: Maintenance Workflow ..................................................................... 33

Chapter 9: Extra Credential Workflow ............................................................. 35

Chapter 10: Client-Managed Authentication ............................................... 41

Chapter 11: Transaction Notification Workflow ........................................ 47

Chapter 12: Customer Service Workflows .................................................... 49

Chapter 13: Out-Of-Band Email Authentication Workflow ................. 57

Challenge SOAP Response for OOB Email .............................................................110

Authenticate SOAP Response for Secret Questions (Failed) ................................. 152

1 Understanding the Workflows

Workflows Description Dependent Workflows

Logon Authentication Allows a user to sign in to your system. Enrollment

Logon Monitoring Allows a user to sign in to your system.

1: Understanding the Workflows 9

Workflows Description Dependent Workflows

Transaction Checks the risk of a given user transaction after Enrollment

Transaction Monitoring Collects information on user-specific transaction.

Workflows Description Dependent Workflows

Enrollment Enrolls a user into the Adaptive Authentication

User Maintenance Allows a user to update account information, such Enrollment

Extra Credential Allows a user to perform further authentication Enrollment

Client-Managed Allows you to use your own authentication Sign in

Transaction Notification Allows your institution to send additional Transaction Notification

10 1: Understanding the Workflows

Customer Service Workflows

Workflows Description Dependent Workflows

Unlocking a User Account Allows a customer service Enrollment

Locking a User Account Allows a customer service Enrollment

Resetting a User Account Allows a customer service Enrollment

Deleting a User Account Allows a customer service Enrollment

Partially Reenrolling Allows a customer to partially reenroll Locking a User Account

Sign in Types Description

1: Understanding the Workflows 11

Sign in Types Description

Sign in Monitoring Designed to have no impact on the current user

Transaction Types Description

Transaction Monitoring Does not challenge users.

12 1: Understanding the Workflows

User Browser Organization's Web Site Adaptive Authentication

1. Request logon/initiate transaction

2. Display logon/transaction form

3. Gather device data (IP address, Browser information,

4. Submit form details + device data

5. Call Analyze to calculate risk score

9. Respond with the challenge questions

11. Submit the answers

12. Call Authenticate

13. Respond with authentication status

14. Display the main page

Note: By default, challenge questions are used as the secondary

Note: Ensure to include sessionId and transactionId.

3 Logon Monitoring Workflow

User Browser Organization's Web Site Adaptive Authentication