Вы находитесь на странице: 1из 155

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Workflows Description Dependent Workflows

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.

Workflows Description Dependent Workflows

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

Workflows Description Dependent Workflows

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 state is VERIFIED.
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.

User Browser Organization's Web Site Adaptive Authentication

1. Request logon

2. Display logon form

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


fingerprint, deviceTokenCookie, deviceTokenFSO)
4. Submit logon details + device data

5. Verify user credentials


6. Call Analyze to calculate risk score

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.
3. The data-gathering JavaScript executes as the logon page loads and collects the
device forensic data.

3: Logon Monitoring Workflow 17


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 organization verifies 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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 state is VERIFIED.
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.

User Browser Organization's Web Site Adaptive Authentication

1. Initiate transaction

2. Display the transaction page

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

4. Submit transaction details + device data

5. Call Analyze to calculate risk score

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

9. Respond with the challenge questions

10. Challenge user for secondary authentication (In this example, challenge questions are used)

11. Submit the answers


12. Call Authenticate

13. Respond with authentication status

14. Display the transaction success page

4: Transaction Authentication Workflow 19


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
The following elements must be included in the SOAP message:
ANALYZE request: genericActionTypes=GET_USER_STATUS,
devicePrint, ipAddress, userName, userType,
eventType=PAYMENT, transactionData, riskType=ALL
6. The Risk Engine processes the information in the analyze request and applies
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.
The following elements must be included in the SOAP message:
CHALLENGE request: sessionId, transactionId,
challengeQuestionChallengeRequest(numberOfQuestion),
9. Adaptive Authentication sends a challenge response with the questions.
The following elements are returned in the SOAP message:
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.
The following elements must be included in the SOAP message:
AUTHENTICATE request: devicePrint, sessionId, transactionId,
deviceToken, ipAddress, challengeQuestion(userAnswer)

20 4: Transaction Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

13. Adaptive Authentication sends an authenticate response with the authentication


status. In this example, the user is successfully authenticated.
The following elements are returned in the SOAP message:
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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 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.
8. The Risk Engine processes the information in the analyze request and applies
policies.
9. The Adaptive Authentication system sends an analyze response with the
recommended policy action. In this example, the user is allowed to continue the
enrollment process.
For a sample SOAP message, see Analyze SOAP Response for OOB Email on
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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:
The user state is VERIFIED.
(Optional) The user device is bound if selected by the user.

26 5: Enrollment Workflow
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

User Browser Organization's Web Site Adaptive Authentication

1. Initiate transaction

2. Display the transaction page

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


fingerprint, deviceTokenCookie, deviceTokenFSO)
4. Submit transaction details + device data

5. Call Analyze to calculate risk score

6. Calculate the risk


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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
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 contain the device data, browser information, IP
address, user name, user type, action type, and event type.
For a sample SOAP message, see Analyze SOAP Request for OOB Email on
page 107.
6. The Risk Engine processes the information in the analyze request and applies
policies.
7. The Adaptive Authentication system sends an analyze response with the result.
For a sample SOAP message, see Analyze SOAP Response for OOB Email on
page 108.
8. The transaction success page is displayed to the user regardless of the
recommended policy action.

28 6: Transaction Monitoring Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

The following figure displays the maintenance workflow.

34 8: Maintenance Workflow
RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
2. Recommend an action.
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:

9: Extra Credential Workflow 37


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

The following figure displays the challenge questions workflow.

9: Extra Credential Workflow 39


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
2. Recommend an action.
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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

10: Client-Managed Authentication 43


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

The following figure displays the client-managed credentials workflow.

10: Client-Managed Authentication 45


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

The following figure displays the transaction notification workflow.

48 11: Transaction Notification Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
2. The customer service representative validates the users identity, if necessary.
3. The customer service representative submits an unlock request to the Adaptive
Authentication system.
4. One of the following occurs:

50 12: Customer Service Workflows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
2. The customer service representative validates the users identity, if necessary.
3. The customer service representative submits a reset request to the Adaptive
Authentication system.
4. The user is set to RESET.
5. The user is required to log on and choose new challenge questions along with
corresponding answers.

12: Customer Service Workflows 51


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
2. The customer service representative validates the users identity, if necessary.
3. The customer service representative submits a delete request to the Adaptive
Authentication system.
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.

52 12: Customer Service Workflows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

12: Customer Service Workflows 53


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

54 12: Customer Service Workflows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

12: Customer Service Workflows 55


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 state is VERIFIED.
The user is successfully enrolled for OOB email with the Adaptive Authentication
system.

13: Out-Of-Band Email Authentication Workflow 57


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

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

11. Challenge user for secondary authentication

12. Submit the answers


13. Call Authenticate

14. Validate the following:


- OTP entered matches
- OTP has not expired
- OTP is not reused
15. Respond with authentication status

16. Display the main page

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 OOB Email on
page 107.
6. The Risk Engine processes the information in the analyze request and applies
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.
For a sample SOAP message, see Analyze SOAP Response for OOB Email on
page 108.
8. The website sends the challenge request message to retrieve information for
secondary authentication. In this example, secondary authentication is done by
OOB email.
The challenge request must include the device data, browser information, IP
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.
11. The website of the organization prompts the user for secondary authentication.
12. User enters the answer and clicks the submit button.
The website must retrieve and send the device forensic data to the Adaptive
Authentication system.
13. The website 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 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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
16. The secure page is displayed to the user.

60 13: Out-Of-Band Email Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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
the authentication status.
If there are system errors during the authentication process, the response message
indicates NULL status.

14: Out-Of-Band Phone Authentication Workflow 61


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
3. The data-gathering JavaScript runs as the page loads and collects the device data,
such as the IP address, browser information, device fingerprint,
deviceTokenCookie, and deviceTokenFSO.

62 14: Out-Of-Band Phone Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

4. The end user enters the logon or transaction details and clicks the submit button.
The device forensic data is sent along with the transaction details.
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.
8. Adaptive Authentication sends an analyze response message with the
recommended policy action and the list of available challenge methods. The list of
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
activity and sends the challenge response.
11. Adaptive Authentication sends an analyze response message with the
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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

15 Knowledge-Based Authentication Workflow


During 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 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 state is VERIFIED.
The user is successfully enrolled for KBA with the Adaptive Authentication
system.

15: Knowledge-Based Authentication Workflow 65


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

This following image illustrates the general message flow during the KBA
authentication.

KBA System
User Browser Organizations Web Site Adaptive Authentication

1. Request logon/initiate transaction


2. Display logon/transaction form

3. Gather device data (IP address,


Browser information, fingerprint,
deviceTokenCookie, and
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 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


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.

66 15: Knowledge-Based Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
7. The Adaptive Authentication system sends an analyze response with the
recommended policy action and the list of available challenge methods.
The list of challenge methods consists 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, 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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
18. The secure page is displayed to the user.

68 15: Knowledge-Based Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

16 Out-Of-Band SMS 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) 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 state is VERIFIED.
The user is successfully enrolled for OOB SMS with the Adaptive Authentication
system.

16: Out-Of-Band SMS Authentication Workflow 69


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

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

11. Challenge user for secondary authentication

12. Submit the answers


13. Call Authenticate

14. Validate the following:


- OTP entered matches
- OTP has not expired
- OTP is not reused
15. Respond with authentication status

16. Display the main page

OOB SMS 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.

70 16: Out-Of-Band SMS Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 OOB SMS on
page 129.
6. The information in the analyze request is processed by the Risk Engine.
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 consists 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) SMS is used.
For a sample SOAP message, see Analyze SOAP Response for OOB SMS on
page 130.
8. The website sends the challenge request message to retrieve information for
secondary authentication. In this example, secondary authentication is done by
OOB SMS.
The challenge request must include the device data, browser information, IP
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
activity and sends the challenge response.
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.
11. The website of the organization prompts the user for secondary authentication.
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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

13. The website 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 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.
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 SMS
(Successful) on page 135.
16. The secure page is displayed to the user.

72 16: Out-Of-Band SMS Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

17 One-Time Password Authentication


Workflow
During a user logon or transaction, if the users action is found to be risky, the user is
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 state is VERIFIED.
The user is successfully enrolled for one-time password with the RSA Adaptive
Authentication (On-Premise) system.

17: One-Time Password Authentication Workflow 73


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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

User Browser Organizations Web Site Adaptive Authentication

1. Request logon/initiate transaction


2. Display logon/transaction form

3. Gather device data (IP address,


Browser information, fingerprint,
deviceTokenCookie, and
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 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.)
12. Submit the answers

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


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.

74 17: One-Time Password Authentication Workflow


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
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 OTP on page 138.
6. The information in the analyze request is processed by the Risk Engine.
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 consists 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, 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
Authentication system.
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.
15. The Adaptive Authentication system sends an authenticate response message with
the authentication status.
Authenticate SOAP Response for OTP (Successful) on page 144
16. The secure page is displayed to the user.

17: One-Time Password Authentication Workflow 75


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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 state is VERIFIED.
The user has an account with the website of the organization. The user is enrolled
and is verified.

18: Failed Authentication Workflow 77


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.

User Browser Organizations Web Site Adaptive Authentication

1. Request logon/initiate transaction


2. Display logon/transaction form

3. Gather device data (IP address,


Browser information, fingerprint,
deviceTokenCookie, and
deviceTokenFSO)

4. Submit form details device data

5. Verify user credentials

6. Call Analyze to calculate risk score


7. Calculate the risk
score and apply
policies

8. Respond with the recommended


action and available challenge methods
(In this example high risk score is generated
and the user is challenged)

9. Call Challenge

10. Respond with the challenge questions


(In this example, challenge questions are
used
11. Challenge user for secondary authentication

12. User submits incorrect answers

13. Call Authenticate

14. User fails


authentication.
Failure Count
15. Respond with authentication status increases by one
(failed)

16. Challenge user for secondary authentication

17. User submits answers

18. Call Authenticate

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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.
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.
During the step, the device data is sent along with the event data.
5. The organization verifies the user credentials.
6. The organizations web application sends the 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 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.
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 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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

13. The organizations web application 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.

Note: Ensure to include sessionId and transactionId.

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

Note: Ensure to include sessionId and transactionId.

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:actionTypeList>
<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


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>HARD_BIND</ns1:bindingType>
<ns1:lookupLabel>device_label</ns1:lookupLabel>
</ns1:deviceData>
</ns1:deviceManagementResponse>
<ns1:riskResult>
<ns1:riskScore>15</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>

A: Sample SOAP Message Flows 83


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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

84 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze Session Sign in 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: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: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>usertest1</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>ANALYZE</ws:requestType>
<ws:version>7.0</ws:version>
</ws:messageHeader>
<ws:securityHeader>
<ws:callerCredential>password1!</ws:callerCredential>
<ws:callerId>callerId</ws:callerId>
<ws:method>PASSWORD</ws:method>
</ws:securityHeader>
<ws:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>SESSION_SIGNIN</ws:eventType>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 85


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze Session Sign in SOAP Response for Allow Action


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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: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>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9%2
B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL
</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fz
u9%2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL
</ns1:deviceTokenFSO>
<ns1:lookupLabel>device_label</ns1:lookupLabel>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>7ff7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-19T14:11:39.584Z</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:riskResult>
<ns1:riskScore>24</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>ALLOW</ns1:actionCode>
<ns1:actionName>userBoundLowRisk</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>userBoundLowRisk</ns1:ruleId>
<ns1:ruleName>userBoundLowRisk</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

86 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User with Unbinding 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:updateUser>
<ws:request>
<ws:deviceRequest>
<ws:deviceTokenCookie>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9%
2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL</ws:deviceTokenCookie>
<ws:deviceTokenFSO>PMV602wNTVMp3vYyBLIiNxYqv9m%2FpTgc0Fzu9
%2B2C7DuNGNGyjamoqBcrPLV4%2FtjMWkQhPL</ws:deviceTokenFSO>
</ws:deviceRequest>
<ws:identificationData>
<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>UPDATEUSER</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:actionTypeList>
<ws:deviceData>
<ws:bindingType>NONE</ws:bindingType>
<ws:lookupLabel>device_label</ws:lookupLabel>
</ws:deviceData>
</ws:deviceManagementRequest>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 87


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User with Unbinding SOAP Response for Allow Action


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:updateUserResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:updateUserReturn xsi:type="ns1:UpdateUserResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:deviceResult>
<ns1:authenticationResult>
<ns1:authStatusCode>SUCCESS</ns1:authStatusCode>
<ns1:risk>100</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>4ff7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:userName>user</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>UPDATEUSER</ns1:requestType>
<ns1:timeStamp>2012-08-19T14:17:29.618Z</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:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<ns1:lookupLabel>device_label</ns1:lookupLabel>
</ns1:deviceData>
</ns1:deviceManagementResponse>
<ns1:riskResult>
<ns1:riskScore>14</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>

88 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

<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: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)

A: Sample SOAP Message Flows 89


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Request for KBA


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:createUser xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:actionTypeList>
<ws:genericActionTypes>SET_USER_STATUS</ws:genericActionTypes>
</ws:actionTypeList>
<ws:identificationData>
<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:credentialManagementRequestList>
<ws:acspManagementRequestData>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload xsi:type="ns401:KBAManagementRequest"
xmlns:ns401="http://ws.kba.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<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:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

90 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for KBA


<ns1:createUserReturn xsi:type="ns1:CreateUserResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:transactionId>e966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:userName>user</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-27T07:52:17.885Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:acspManagementResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAManagementResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com">
<ns2:personInfo>
<ns2:ssnInfo>
<ns2:ssnType>NOSSN</ns2:ssnType>
</ns2:ssnInfo>
<ns2:nameInfo>
<ns2:firstName>****</ns2:firstName>
<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:day>**</ns2:day>
<ns2:month>**</ns2:month>
<ns2:year>****</ns2:year>
</ns2:birthdayInfo>
</ns2:personInfo>
</ns1:payload>
</ns1:acspManagementResponseData>
</ns1:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>2</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>

A: Sample SOAP Message Flows 91


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

<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 SOAP Request for KBA


The following sample displays a SOAP message for the Session Sign in event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:analyze xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:identificationData>
<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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>SESSION_SIGNIN</ws:eventType>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

92 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for KBA


The following sample displays a SOAP message for the Session Sign in event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:sessionId>4bccc90a:1396541c967:-669b</ns1:sessionId>
<ns1:transactionId>a966-:769c1456931:a09cccb4_TRX
</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-27T07:52:32.519Z</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: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:riskScore>2</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>AuthDevNotBound</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>AuthDevNotBound</ns1:ruleId>
<ns1:ruleName>AuthDevNotBound</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 93


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for KBA


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:challenge xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:identificationData>
<ws:sessionId>4bccc90a:1396541c967:-669b</ws:sessionId>
<ws:transactionId>a966-:769c1456931:a09cccb4_TRX
</ws:transactionId>
<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>CHALLENGE</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:credentialChallengeRequestList>
<ws:acspChallengeRequestData>
<ws:payload xsi:type="ns753:KBAChallengeRequest"
xmlns:ns753="http://ws.kba.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</ws:acspChallengeRequestData>
</ws:credentialChallengeRequestList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

94 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for KBA


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:sessionId>4bccc90a:1396541c967:-669b</ns1:sessionId>
<ns1:transactionId>a966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:userName>user</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-27T07:52:39.972Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:acspChallengeResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription>Questions and answers retrieved
successfully from KBA</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAChallengeResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com">
<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:choiceId>8026835568777</ns2:choiceId>
<ns2:text>Eamon Johnson</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568778</ns2:choiceId>
<ns2:text>Eileen Prestwood</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568779</ns2:choiceId>
<ns2:text>Neil Owen</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568780</ns2:choiceId>
<ns2:text>Sheena Ishmail</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568781</ns2:choiceId>

A: Sample SOAP Message Flows 95


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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


</ns2:choices>
</ns2:questions>
<ns2:questions>
<ns2:questionId>8022125922659</ns2:questionId>
<ns2:text>In which of the following districts or locations
have you ever lived?</ns2:text>
<ns2:choices>
<ns2:choiceId>8026835568782</ns2:choiceId>
<ns2:text>Cefn Cribwr</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568783</ns2:choiceId>
<ns2:text>Dyce</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568784</ns2:choiceId>
<ns2:text>Norbury</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568785</ns2:choiceId>
<ns2:text>Send</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568786</ns2:choiceId>
<ns2:text>Twyford</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568787</ns2:choiceId>
<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:choiceId>8026835568788</ns2:choiceId>
<ns2:text>January</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568789</ns2:choiceId>
<ns2:text>March</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568790</ns2:choiceId>
<ns2:text>May</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568791</ns2:choiceId>
<ns2:text>August</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568792</ns2:choiceId>
<ns2:text>October</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026835568793</ns2:choiceId>
<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>

96 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Request for KBA


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:authenticate xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:identificationData>
<ws:sessionId>4bccc90a:1396541c967:-669b</ws:sessionId>
<ws:transactionId>a966-:769c1456931:a09cccb4_TRX
</ws:transactionId>
<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>AUTHENTICATE</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:credentialDataList>
<ws:acspAuthenticationRequestData>
<ws:payload xsi:type="ns977:KBAAuthenticationRequest"
xmlns:ns977="http://ws.kba.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns977:answers>
<ns977:questionId>8022125922658</ns977:questionId>
<ns977:choiceIds>8026835568781</ns977:choiceIds>
</ns977:answers>
<ns977:answers>
<ns977:questionId>8022125922659</ns977:questionId>
<ns977:choiceIds>8026835568787</ns977:choiceIds>
</ns977:answers>
<ns977:answers>
<ns977:questionId>8022125922660</ns977:questionId>
<ns977:choiceIds>8026835568793</ns977:choiceIds>
</ns977:answers>
</ws:payload>
</ws:acspAuthenticationRequestData>
</ws:credentialDataList>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 97


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:sessionId>4bccc90a:1396541c967:-6671</ns1:sessionId>
<ns1:transactionId>0766-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-27T08:07:37.353Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<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: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:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

98 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:sessionId>4bccc90a:1396541c967:-666b</ns1:sessionId>
<ns1:transactionId>a666-:769c1456931:a09cccb4_TRX
</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-27T08:08:18.183Z</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:credentialAuthResultListxsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<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"
xmlns:ns2="http://ws.kba.csd.rsa.com">
<ns2:questions>
<ns2:questionId>8022125309625</ns2:questionId>
<ns2:text>In which of the following districts or
locations have you ever lived?</ns2:text>
<ns2:choices>
<ns2:choiceId>8026838496250</ns2:choiceId>
<ns2:text>Colden Common</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026838496251</ns2:choiceId>
<ns2:text>Coleford</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026838496252</ns2:choiceId>
<ns2:text>Finsbury Park</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026838496253</ns2:choiceId>
<ns2:text>Lochee</ns2:text>
</ns2:choices>

A: Sample SOAP Message Flows 99


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

<ns2:choices>
<ns2:choiceId>8026838496254</ns2:choiceId>
<ns2:text>Pill</ns2:text>
</ns2:choices>
<ns2:choices>
<ns2:choiceId>8026838496255</ns2:choiceId>
<ns2:text>I have never lived or owned property
in any of these districts</ns2:text>
</ns2:choices>
</ns2:questions>
</ns1:payload>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
<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:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

100 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:transactionId>a966-:769c1456931:a09cccb4_TRX
</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-27T07:52:50.522Z</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:credentialAuthResultListxsi:type=
"ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription>Answers match in
KBA</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>

A: Sample SOAP Message Flows 101


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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)

102 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Request for OOB Email


<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:identificationData>
<ws:userName>user10</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:credentialManagementRequestList>
<ws:oobEmailManagementRequest>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<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:credentialManagementRequestList>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 103


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for OOB Email


<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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:transactionId>fff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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-20T07:43:44.888Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:oobEmailManagementResponse>
<ns1:payload xsi:type="ns1:EmailManagementResponsePayload">
<ns1:acspAccountId>user10</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</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:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>4</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>

104 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User SOAP Request for OOB Email


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:updateUser>
<ws:request>
<ws:actionTypeList>
<ws:genericActionTypes>SET_PHRASE</ws:genericActionTypes>
</ws:actionTypeList>
<ws:identificationData>
<ws:userName>user10</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>UPDATEUSER</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:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 105


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User SOAP Response for OOB Email


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:updateUserResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:updateUserReturn xsi:type="ns1:UpdateUserResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>dff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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>UPDATEUSER</ns1:requestType>
<ns1:timeStamp>2012-08-20T07:44:00.727Z</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:riskResult>
<ns1:riskScore>4</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:updateUserReturn>
</ns1:updateUserResponse>
</soapenv:Body>
</soapenv:Envelope>

106 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Request for OOB Email


The following sample displays a SOAP message for the Payment event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:ipAddress>30.30.30.30</ws:ipAddress>
</ws:deviceRequest>
<ws:identificationData>
<ws:userName>user10</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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<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:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 107


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for OOB Email


The following sample displays a SOAP message for the Payment event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<ns1:deviceTokenCookie>PMV602EbovpQBP4%2FXLTti6rJNqjrcXjQOFhN
%2B4okMH7zrAZ6i1ewPbOmeqXWhMMT%2BGCZMS
</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV602EbovpQBP4%2FXLTti6rJNqjrcXjQOFhN%
2B4okMH7zrAZ6i1ewPbOmeqXWhMMT%2BGCZMS</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>-59685e99:13942fcc431:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-20T07:55:37.971Z</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:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>OOBEMAIL</ns1:credentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:riskScore>1000</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_4</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>IPOnWatchList</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>IPOnWatchList</ns1:ruleId>
<ns1:ruleName>IPOnWatchList</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

108 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for OOB Email


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:identificationData>
<ws:sessionId>-59685e99:13942fcc431:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ws:transactionId>
<ws:userName>user10</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>CHALLENGE</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:credentialChallengeRequestList>
<ws:oobEmailChallengeRequest>
<ws:payload>
<ws:emailInfo>
<ws:defaultFlag>true</ws:defaultFlag>
<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:credentialChallengeRequestList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 109


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for OOB Email


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>-59685e99:13942fcc431:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-20T07:55:59.812Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:oobEmailChallenge>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>PENDING</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:channelStatus>Status.CREATED</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
</ns1:payload>
</ns1:oobEmailChallenge>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

110 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Request for OOB Email


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:identificationData>
<ws:sessionId>-59685e99:13942fcc431:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ws:transactionId>
<ws:userName>user10</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>AUTHENTICATE</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:credentialDataList>
<ws:oobEmailData>
<ws:payload>
<ws:token>615951</ws:token>
</ws:payload>
</ws:oobEmailData>
</ws:credentialDataList>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 111


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OOB Email (Failed)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>-59685e99:13942fcc431:-7ff1</ns1:sessionId>
<ns1:transactionId>0ff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-20T08:06:17.402Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:oobEmailAuthResult>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>80</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_FAILED</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
</ns1:payload>
</ns1:oobEmailAuthResult>
</ns1:credentialAuthResultList>
<ns1:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>OOBEMAIL</ns1:credentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

112 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OOB Email (Success)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>5ff7-:134ccf24931:99e58695-_TRX</ns1:transactionId>
<ns1:userName>user10</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-20T07:56:53.963Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:oobEmailAuthResult>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>SUCCESS</ns1:authStatusCode>
<ns1:risk>80</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_SUCCESS</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
</ns1:payload>
</ns1:oobEmailAuthResult>
</ns1:credentialAuthResultList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 113


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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)

114 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Request for OOB Phone


<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:identificationData>
<ws:delegated>true</ws:delegated>
<ws:orgName>org</ws:orgName>
<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:credentialManagementRequestList>
<ws:oobPhoneManagementRequest>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload>
<ws:oobActionTypeList>
<ws:oobActionType>ADD_OOB</ws:oobActionType>
</ws:oobActionTypeList>
<ws:contactList>
<ws:defaultFlag>true</ws:defaultFlag>
<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:credentialManagementRequestList>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 115


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for OOB Phone


<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:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>fff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:userName>user</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-22T08:43:59.612Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:oobPhoneManagementResponse>
<ns1:payload xsi:type="ns1:PhoneManagementResponsePayload">
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</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:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>0</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>

116 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Request for OOB Phone


The following sample displays a SOAP message for the Add Payee event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:ipAddress>10.10.10.0</ws:ipAddress>
</ws:deviceRequest>
<ws:identificationData>
<ws:delegated>true</ws:delegated>
<ws:orgName>org</ws:orgName>
<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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ADD_PAYEE</ws:eventType>
<ws:transactionData>
<ws:otherAccountBankType>SAME_BANK</ws:otherAccountBankType>
<ws:otherAccountData>
<ws:accountNumber>123456</ws:accountNumber>
<ws:accountOwnershipType>BUSINESS</ws:accountOwnershipType>
</ws:otherAccountData>
<ws:otherAccountOwnershipType>ME_TO_YOU
</ws:otherAccountOwnershipType>
<ws:otherAccountType>BILLER</ws:otherAccountType>
</ws:transactionData>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 117


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for OOB Phone


The following sample displays a SOAP message for the Add Payee event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<ns1:deviceTokenCookie>PMV600EZq5vSB%2BJFjaGcTNuwlhcQw%2FXKKgmZtT
G1bMZ1AGuEOFJKThgc3cD%2FEYBZJhNQ9g</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV600EZq5vSB%2BJFjaGcTNuwlhcQw%2FXKKgmZtTG
1bMZ1AGuEOFJKThgc3cD%2FEYBZJhNQ9g</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>-7b3a725d:1394d80a375:-7ffe</ns1:sessionId>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-22T08:44:36.885Z</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:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>OOBPHONE</ns1:credentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:riskScore>10</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>CountryOnWatchList</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>CountryOnWatchList</ns1:ruleId>
<ns1:ruleName>CountryOnWatchList</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

118 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for OOB Phone


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:identificationData>
<ws:orgName>org</ws:orgName>
<ws:sessionId>-7b3a725d:1394d80a375:-7ffe</ws:sessionId>
<ws:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ws:transactionId>
<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>CHALLENGE</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:credentialChallengeRequestList>
<ws:oobPhoneChallengeRequest>
<ws:payload>
<ws:noOp>false</ws:noOp>
<ws:phoneInfo>
<ws:defaultFlag>true</ws:defaultFlag>
<ws:label>work</ws:label>
<ws:areaCode>074</ws:areaCode>
<ws:countryCode>972</ws:countryCode>
<ws:phoneNumber>7380000</ws:phoneNumber>
</ws:phoneInfo>
<ws:tokenCollectionFlow>true</ws:tokenCollectionFlow>
</ws:payload>
</ws:oobPhoneChallengeRequest>
</ws:credentialChallengeRequestList>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ADD_PAYEE</ws:eventType>
</ws:eventData>
</ws:eventDataList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 119


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for OOB Phone


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>-7b3a725d:1394d80a375:-7ffe</ns1:sessionId>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
</ns1:transactionId>
<ns1:userName>user</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-22T08:51:17.593Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:oobPhoneChallenge>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>PENDING</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:channelStatus>Status.CREATED</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
<ns1:token>042985</ns1:token>
</ns1:payload>
</ns1:oobPhoneChallenge>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

120 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Query Authentication Status SOAP Request for OOB Phone


<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:queryAuthStatus>
<ws:request>
<ws:identificationData>
<ws:orgName>org</ws:orgName>
<ws:sessionId>-7b3a725d:1394d80a375:-7ffe</ws:sessionId>
<ws:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
</ws:transactionId>
<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>QUERYAUTHSTATUS</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:credentialAuthStatusRequest>
<ws:oobPhoneAuthStatusRequest>
<ws:payload>
<ws:token>042985</ws:token>
</ws:payload>
</ws:oobPhoneAuthStatusRequest>
</ws:credentialAuthStatusRequest>
</ws:request>
</ws:queryAuthStatus>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 121


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Query Authentication Status SOAP Response for OOB Phone (Failed)


<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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>-7b3a725d:1394d80a375:-7ffe</ns1:sessionId>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX</ns1:transactionId>
<ns1:userName>user</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>QUERYAUTHSTATUS</ns1:requestType>
<ns1:timeStamp>2012-08-22T08:52:37.727Z</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:credentialAuthStatusResponse
xsi:type="ns1:CredentialAuthStatusResponse">
<ns1:oobPhoneAuthStatusResponse>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>80</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:channelStatus>Status.CHALLENGE_FAILED</ns1:channelStatus>
<ns1:reason>Reason.CONFIRMATION_NUM_FAILURE</ns1:reason>
<ns1:token>042985</ns1:token>
</ns1:payload>
</ns1:oobPhoneAuthStatusResponse>
</ns1:credentialAuthStatusResponse>
</ns1:queryAuthStatusReturn>
</ns1:queryAuthStatusResponse>
</soapenv:Body>
</soapenv:Envelope>

122 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>-7b3a725d:1394d80a375:-7ffe</ns1:sessionId>
<ns1:transactionId>dff7-:573a08d4931:d527a3b7-_TRX
</ns1:transactionId>
<ns1:userName>user</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>QUERYAUTHSTATUS</ns1:requestType>
<ns1:timeStamp>2012-08-22T08:50:28.622Z</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:credentialAuthStatusResponse
xsi:type="ns1:CredentialAuthStatusResponse">
<ns1:oobPhoneAuthStatusResponse>
<ns1:payload>
<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:channelStatus>Status.CHALLENGE_SUCCESS
</ns1:channelStatus>
<ns1:reason>NONE</ns1:reason>
<ns1:token>519017</ns1:token>
</ns1:payload>
</ns1:oobPhoneAuthStatusResponse>
</ns1:credentialAuthStatusResponse>
</ns1:queryAuthStatusReturn>
</ns1:queryAuthStatusResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 123


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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)

124 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Request for OOB SMS


<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:identificationData>
<ws:groupName>group</ws:groupName>
<ws:orgName>org</ws:orgName>
<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:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 125


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for OOB SMS


<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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>fff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</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-22T16:42:58.824Z</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:riskResult>
<ns1:riskScore>8</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>

126 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User SOAP Request for OOB SMS


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:updateUser>
<ws:request>
<ws:identificationData>
<ws:groupName>group</ws:groupName>
<ws:orgName>org</ws:orgName>
<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>UPDATEUSER</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:credentialManagementRequestList>
<ws:acspManagementRequestData>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload xsi:type="ns934:OOBSMSManagementRequest"
xmlns:ns934="http://ws.oobsms.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<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:acspManagementRequestData>
</ws:credentialManagementRequestList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:updateUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 127


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Update User SOAP Response for OOB SMS


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:updateUserResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:updateUserReturn xsi:type="ns1:UpdateUserResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>dff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</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>UPDATEUSER</ns1:requestType>
<ns1:timeStamp>2012-08-22T16:43:15.166Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:acspManagementResponseData>
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</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:acspManagementResponseData>
</ns1:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>8</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:updateUserReturn>
</ns1:updateUserResponse>
</soapenv:Body>
</soapenv:Envelope>

128 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Request for OOB SMS


The following sample displays a SOAP message for the Active Card event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:ipAddress>10.10.10.0</ws:ipAddress>
</ws:deviceRequest>
<ws:identificationData>
<ws:groupName>group</ws:groupName>
<ws:orgName>org</ws:orgName>
<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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>ACTIVATE_CARD</ws:eventType>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 129


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for OOB SMS


The following sample displays a SOAP message for the Active Card event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>4ff806f:1394f372a0e:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-22T16:48:11.41Z</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:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>USER_DEFINED</ns1:credentialType>
<ns1:genericCredentialType>OOBSMS</ns1:genericCredentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:riskScore>968</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_4</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>CountryOnWatchList</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>CountryOnWatchList</ns1:ruleId>
<ns1:ruleName>CountryOnWatchList</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

130 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for OOB SMS


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:identificationData>
<ws:groupName>group</ws:groupName>
<ws:orgName>org</ws:orgName>
<ws:sessionId>4ff806f:1394f372a0e:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ws:transactionId>
<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>CHALLENGE</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:credentialChallengeRequestList>
<ws:acspChallengeRequestData>
<ws:payload xsi:type="ns157:OOBSMSChallengeRequest"
xmlns:ns157="http://ws.oobsms.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ws:contactList xmlns:ws="http://ws.oobgen.csd.rsa.com">
<ws:isDefault>true</ws:isDefault>
<ws:phoneNumber>2500000</ws:phoneNumber>
<ws:countryCode>972</ws:countryCode>
<ws:areaCode>54</ws:areaCode>
<ws:label>my mobile</ws:label>
</ws:contactList>
</ws:payload>
</ws:acspChallengeRequestData>
</ws:credentialChallengeRequestList>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 131


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for OOB SMS


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>4ff806f:1394f372a0e:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-22T16:48:54.779Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:acspChallengeResponseData>
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>PENDING</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSChallengeResponse"
xmlns:ns3="http://ws.oobsms.csd.rsa.com"/>
</ns1:acspChallengeResponseData>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

132 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Request for OOB SMS


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:identificationData>
<ws:groupName>group</ws:groupName>
<ws:orgName>org</ws:orgName>
<ws:sessionId>4ff806f:1394f372a0e:-7ff6</ws:sessionId>
<ws:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ws:transactionId>
<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>AUTHENTICATE</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:credentialDataList>
<ws:acspAuthenticationRequestData>
<ws:payload xsi:type="ns417:OOBSMSAuthenticationRequest"
xmlns:ns417="http://ws.oobsms.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ws:otp xmlns:ws="http://ws.oobsms.csd.rsa.com">0nbf7X</ws:otp>
</ws:payload>
</ws:acspAuthenticationRequestData>
</ws:credentialDataList>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 133


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OOB SMS (Failed)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>4ff806f:1394f372a0e:-7ff6</ns1:sessionId>
<ns1:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-22T16:49:31.563Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>FAIL</ns1:statusCode>
<ns1:statusDescription>OTP doesn't match</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSAuthenticationResponse"
xmlns:ns3="http://ws.oobsms.csd.rsa.com"/>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
<ns1:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>USER_DEFINED</ns1:credentialType>
<ns1:genericCredentialType>OOBSMS</ns1:genericCredentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

134 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OOB SMS (Successful)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>5ff7-:e0a273f4931:f608ff4_TRX</ns1:transactionId>
<ns1:userName>user</ns1:userName>
<ns1:userStatus>LOCKOUT</ns1:userStatus>
<ns1:userType>PERSISTENT</ns1:userType>
</ns1:identificationData>
<ns1:messageHeader>
<ns1:apiType>DIRECT_SOAP_API</ns1:apiType>
<ns1:requestType>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-22T16:50:23.570Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription>OTP matches</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns3:OOBSMSAuthenticationResponse"
xmlns:ns3="http://ws.oobsms.csd.rsa.com"/>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</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

A: Sample SOAP Message Flows 135


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OTP (Failed)


Authenticate SOAP Response for OTP (Successful)

Create User SOAP Request for OTP


<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: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:credentialManagementRequestList>
<ws:acspManagementRequestData>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload xsi:type="ws:OTPManagementRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ws:opcode/>
</ws:payload>
</ws:acspManagementRequestData>
</ws:credentialManagementRequestList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

136 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for OTP


<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:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:transactionId>9df7-:3f8d0be4931:d36fd4e7_TRX
</ns1:transactionId>
<ns1:userName>user</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-22T15:24:18.44Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:acspManagementResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPManagementResponse"/>
</ns1:acspManagementResponseData>
</ns1:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>5</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>

A: Sample SOAP Message Flows 137


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Request for OTP


The following sample displays a SOAP message for the Request Credit event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:identificationData>
<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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>REQUEST_CREDIT</ws:eventType>
<ws:transactionData>
<ws:myAccountData>
<ws:accountName>accountName</ws:accountName>
<ws:accountNumber>123456</ws:accountNumber>
<ws:internationalAccountNumber>123456
</ws:internationalAccountNumber>
<ws:accountOwnershipType>INDIVIDUAL
</ws:accountOwnershipType>
</ws:myAccountData>
</ws:transactionData>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

138 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for OTP


The following sample displays a SOAP message for the Request Credit event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ns1:sessionId>
<ns1:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX
</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-22T15:24:24.928Z</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:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>USER_DEFINED</ns1:credentialType>
<ns1:genericCredentialType>OTP</ns1:genericCredentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:riskScore>5</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>HighEfnScore</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>HighEfnScore</ns1:ruleId>
<ns1:ruleName>HighEfnScore</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 139


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for OTP


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:identificationData>
<ws:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ws:sessionId>
<ws:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ws:transactionId>
<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>CHALLENGE</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:credentialChallengeRequestList>
<ws:acspChallengeRequestData>
<ws:payload xsi:type="ws:OTPChallengeRequest"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</ws:acspChallengeRequestData>
</ws:credentialChallengeRequestList>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

140 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for OTP


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ns1:sessionId>
<ns1:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX
</ns1:transactionId>
<ns1:userName>user</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-22T15:26:04.363Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:acspChallengeResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription>OTP allocated</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPChallengeResponse">
<ns1:otp>742705</ns1:otp>
</ns1:payload>
</ns1:acspChallengeResponseData>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 141


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Request for OTP


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:identificationData>
<ws:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ws:sessionId>
<ws:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ws:transactionId>
<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>AUTHENTICATE</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:credentialDataList>
<ws:acspAuthenticationRequestData>
<ws:payload xsi:type="ws:OTPAuthenticationRequest"
xmlns:ns318="http://ws.oobsms.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ws:otp>742705</ws:otp>
</ws:payload>
</ws:acspAuthenticationRequestData>
</ws:credentialDataList>
<ws:channelIndicator>WEB</ws:channelIndicator>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

142 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OTP (Failed)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:sessionId>7e4df63d:1394eb0d8f3:-7fd8</ns1:sessionId>
<ns1:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX
</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-22T15:25:32.150Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>FAIL</ns1:statusCode>
<ns1:statusDescription>OTP doesn't
match</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPAuthenticationResponse"/>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
<ns1:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>USER_DEFINED</ns1:credentialType>
<ns1:genericCredentialType>OTP</ns1:genericCredentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 143


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for OTP (Successful)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:transactionId>7df7-:3f8d0be4931:d36fd4e7_TRX</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-22T15:26:15.124Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:acspAuthenticationResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription>OTP matches</ns1:statusDescription>
</ns1:callStatus>
<ns1:payload xsi:type="ns1:OTPAuthenticationResponse"/>
</ns1:acspAuthenticationResponseData>
</ns1:credentialAuthResultList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</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)

144 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Request for Secret Questions


<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:identificationData>
<ws:delegated>true</ws:delegated>
<ws:orgName>org</ws:orgName>
<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:credentialManagementRequestList>
<ws:challengeQuestionManagementRequest>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload>
<ws:actionTypeList>
<ws:challengeQuestionActionType>SET_USER_QUESTION
</ws:challengeQuestionActionType>
</ws:actionTypeList>
<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:credentialManagementRequestList>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:createUser>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 145


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Create User SOAP Response for Secret Questions


<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:identificationData>
<ns1:delegated>true</ns1:delegated>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>5df7-:c77173f3931:78c359c7_TRX
</ns1:transactionId>
<ns1:userName>user</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-19T15:24:56.349Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:challengeQuestionManagementResponse>
<ns1:payload>
<ns1:acspAccountId>user@org</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
</ns1:payload>
</ns1:challengeQuestionManagementResponse>
</ns1:credentialManagementResponseList>
<ns1:riskResult>
<ns1:riskScore>9</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>

146 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Request for Secret Questions


The following sample displays a SOAP message for the Session sign in event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:analyze>
<ws:request>
<ws:deviceRequest>
<ws:devicePrint><![CDATA[version=&amp;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&amp;
pm_fpsc=32|1280|1024|996&amp;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&amp;
pm_fptz=-7&amp;pm_fpln=lang=en-us|syslang=en-us|
userlang=en-us&amp;pm_fpjv=1&amp;pm_fpco=1]]>
</ws:devicePrint>
<ws:ipAddress>11.224.14.15</ws:ipAddress>
</ws:deviceRequest>
<ws:identificationData>
<ws:orgName>org</ws:orgName>
<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>ANALYZE</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:autoCreateUserFlag>false</ws:autoCreateUserFlag>
<ws:eventDataList>
<ws:eventData>
<ws:eventType>SESSION_SIGNIN</ws:eventType>
</ws:eventData>
</ws:eventDataList>
<ws:runRiskType>ALL</ws:runRiskType>
</ws:request>
</ws:analyze>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 147


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Analyze SOAP Response for Secret Questions


The following sample displays a SOAP message for the Session sign in event type.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<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:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>0</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:deviceData>
<ns1:bindingType>NONE</ns1:bindingType>
<ns1:deviceTokenCookie>PMV602kFUUIt2OSwKe6VUKh2suovadSSIg%
2BROPI5Xxuf2TxDj2Q3E2yKFlrcu8SM7FbtF7</ns1:deviceTokenCookie>
<ns1:deviceTokenFSO>PMV602kFUUIt2OSwKe6VUKh2suovadSSIg%
2BROPI5Xxuf2TxDj2Q3E2yKFlrcu8SM7FbtF7</ns1:deviceTokenFSO>
</ns1:deviceData>
</ns1:deviceResult>
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>7c953c87:1393f37177c:-7fd4</ns1:sessionId>
<ns1:transactionId>3df7-:c77173f3931:78c359c7_TRX</ns1:transactionId>
<ns1:userName>user</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>ANALYZE</ns1:requestType>
<ns1:timeStamp>2012-08-19T15:25:37.805Z</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:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>QUESTION</ns1:credentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
<ns1:riskResult>
<ns1:riskScore>19</ns1:riskScore>
<ns1:riskScoreBand>SCORE_BAND_0</ns1:riskScoreBand>
<ns1:triggeredRule>
<ns1:actionCode>CHALLENGE</ns1:actionCode>
<ns1:actionName>AuthDevNotBound</ns1:actionName>
<ns1:actionType>STRICT</ns1:actionType>
<ns1:clientFactList/>
<ns1:ruleId>AuthDevNotBound</ns1:ruleId>
<ns1:ruleName>AuthDevNotBound</ns1:ruleName>
</ns1:triggeredRule>
</ns1:riskResult>
</ns1:analyzeReturn>
</ns1:analyzeResponse>
</soapenv:Body>
</soapenv:Envelope>

148 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Request for Secret Questions


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:challenge>
<ws:request>
<ws:identificationData>
<ws:orgName>org</ws:orgName>
<ws:sessionId>7c953c87:1393f37177c:-7fdb</ws:sessionId>
<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>CHALLENGE</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:credentialChallengeRequestList>
<ws:challengeQuestionChallengeRequest>
<ws:payload>
<ws:numberOfQuestion>1</ws:numberOfQuestion>
</ws:payload>
</ws:challengeQuestionChallengeRequest>
</ws:credentialChallengeRequestList>
</ws:request>
</ws:challenge>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 149


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Challenge SOAP Response for Secret Questions


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:challengeResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:challengeReturn xsi:type="ns1:ChallengeResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>7c953c87:1393f37177c:-7fdb</ns1:sessionId>
<ns1:transactionId>9df7-:c77173f3931:78c359c7_TRX
</ns1:transactionId>
<ns1:userName>user</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>CHALLENGE</ns1:requestType>
<ns1:timeStamp>2012-08-19T15:14:34.371Z</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:credentialChallengeList xsi:type="ns1:CredentialChallengeList">
<ns1:challengeQuestionChallenge>
<ns1:payload>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</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>
</ns1:credentialChallengeList>
</ns1:challengeReturn>
</ns1:challengeResponse>
</soapenv:Body>
</soapenv:Envelope>

150 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Request for Secret Questions


<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://ws.csd.rsa.com">
<soapenv:Header/>
<soapenv:Body>
<ws:authenticate>
<ws:request>
<ws:identificationData>
<ws:orgName>org</ws:orgName>
<ws:sessionId>7c953c87:1393f37177c:-7fdb</ws:sessionId>
<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>AUTHENTICATE</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:credentialDataList>
<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:credentialDataList>
</ws:request>
</ws:authenticate>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 151


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for Secret Questions (Failed)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:sessionId>7c953c87:1393f37177c:-7fd4</ns1:sessionId>
<ns1:transactionId>0df7-:c77173f3931:78c359c7_TRX
</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-19T15:26:41.806Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:challengeQuestionAuthResult>
<ns1:payload>
<ns1:authenticationResult>
<ns1:authStatusCode>FAIL</ns1:authStatusCode>
<ns1:risk>100</ns1:risk>
</ns1:authenticationResult>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:challengeQuestionMatchResult>
<ns1:failCount>1</ns1:failCount>
<ns1:matchCount>0</ns1:matchCount>
</ns1:challengeQuestionMatchResult>
</ns1:payload>
</ns1:challengeQuestionAuthResult>
</ns1:credentialAuthResultList>
<ns1:requiredCredentialList>
<ns1:requiredCredential>
<ns1:credentialType>QUESTION</ns1:credentialType>
<ns1:groupName>DEFAULT</ns1:groupName>
<ns1:preference>0</ns1:preference>
<ns1:required>true</ns1:required>
</ns1:requiredCredential>
</ns1:requiredCredentialList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

152 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Authenticate SOAP Response for Secret Questions (Successful)


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:authenticateResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:authenticateReturn xsi:type="ns1:AuthenticateResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:groupName/>
<ns1:orgName>org</ns1:orgName>
<ns1:transactionId>bcf7-:c77173f3931:78c359c7_TRX
</ns1:transactionId>
<ns1:userName>user</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>AUTHENTICATE</ns1:requestType>
<ns1:timeStamp>2012-08-19T15:31:11.153Z</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:credentialAuthResultList xsi:type="ns1:CredentialAuthResultList">
<ns1:challengeQuestionAuthResult>
<ns1:payload>
<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:challengeQuestionMatchResult>
<ns1:failCount>0</ns1:failCount>
<ns1:matchCount>1</ns1:matchCount>
</ns1:challengeQuestionMatchResult>
</ns1:payload>
</ns1:challengeQuestionAuthResult>
</ns1:credentialAuthResultList>
</ns1:authenticateReturn>
</ns1:authenticateResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 153


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

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:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ws:query xmlns:ws="http://ws.csd.rsa.com">
<ws:request>
<ws:identificationData>
<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>QUERY</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:credentialManagementRequestList>
<ws:acspManagementRequestData>
<ws:credentialProvisioningStatus>ACTIVE
</ws:credentialProvisioningStatus>
<ws:payload xsi:type="ns425:KBAManagementRequest"
xmlns:ns425="http://ws.kba.csd.rsa.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns425:action>GET</ns425:action>
</ws:payload>
</ws:acspManagementRequestData>
</ws:credentialManagementRequestList>
</ws:request>
</ws:query>
</soapenv:Body>
</soapenv:Envelope>

154 A: Sample SOAP Message Flows


RSA Adaptive Authentication (On-Premise) 7.1 Workflows and Processes Guide

Query SOAP Response for KBA

Note: The following SOAP message sample uses the KBA authentication method.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:queryResponse xmlns:ns1="http://ws.csd.rsa.com">
<ns1:queryReturn xsi:type="ns1:QueryResponse"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns1:identificationData>
<ns1:delegated>false</ns1:delegated>
<ns1:transactionId>c966-:769c1456931:a09cccb4_TRX</ns1:transactionId>
<ns1:userName>user</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>QUERY</ns1:requestType>
<ns1:timeStamp>2012-08-27T07:52:23.309Z</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:credentialManagementResponseList
xsi:type="ns1:CredentialManagementResponseList">
<ns1:acspManagementResponseData>
<ns1:acspAccountId>user</ns1:acspAccountId>
<ns1:callStatus>
<ns1:statusCode>SUCCESS</ns1:statusCode>
<ns1:statusDescription/>
</ns1:callStatus>
<ns1:payload xsi:type="ns2:KBAManagementResponse"
xmlns:ns2="http://ws.kba.csd.rsa.com">
<ns2:personInfo>
<ns2:ssnInfo>
<ns2:ssnType>NOSSN</ns2:ssnType>
</ns2:ssnInfo>
<ns2:nameInfo>
<ns2:firstName>****</ns2:firstName>
<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:day>**</ns2:day>
<ns2:month>**</ns2:month>
<ns2:year>****</ns2:year>
</ns2:birthdayInfo>
</ns2:personInfo>
</ns1:payload>
</ns1:acspManagementResponseData>
</ns1:credentialManagementResponseList>
</ns1:queryReturn>
</ns1:queryResponse>
</soapenv:Body>
</soapenv:Envelope>

A: Sample SOAP Message Flows 155