Rsa Securid Access Rsa Securid Authentication API Developers Guide
Rsa Securid Access Rsa Securid Authentication API Developers Guide
Developer's Guide
Contact Information
Trademarks
Dell, RSA, the RSA Logo, EMC and other trademarks, are trademarks of Dell Inc. or its subsidiaries. Other
trademarks may be trademarks of their respective owners. For a list of RSA 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 Dell Inc. or its subsidiaries,
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 Dell Inc.
Third-Party Licenses
This product may include software developed by parties other than RSA. The text of the license agreements
applicable to third-party software in this product may be viewed on the product documentation page on RSA
Link. By using this product, a user of this product agrees to be fully bound by terms of the license agreements.
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 Dell software described in this publication requires an applicable software
license.
Dell Inc. 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." DELL INC. 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 2015-2019 Dell Inc. or its subsidiaries. All Rights Reserved.
April 2019
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
Contents
Preface 6
Product Documentation 6
OpenAPI References 6
Graphics Key 6
Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods 14
Scenario: Assurance level does not include the primary authentication method 17
3
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
Initialize Request 20
Unsupported Parameters 24
Verify Request 26
AuthNResponse Properties 28
Response to Verify 36
AuthNStatusReponse Properties 37
4
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
Cancel Call 39
Cancel Request 39
Cancel Parameters 39
Software Requirements 41
5
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
Preface
RSA SecurID Authentication API is a REST API for developers who want to build clients that send authentication
requests to RSA SecurID Access, either through the RSA Authentication Manager server, the Cloud
Authentication Service, or both.
RSA strongly recommends using the RSA SecurID Authentication API for developing new clients. This document
describes how the REST interface JSON properties are used for authentication and provides guidance for
specific scenarios. Each section describes a REST endpoint interface, the expected way the interface is called,
the server responses the client should be ready to accept, and security aspects the client should be validating.
Product Documentation
For a complete list of RSA SecurID Access documentation, see "RSA SecurID Access Product Documentation" on
RSA Link at https://community.rsa.com/docs/DOC-60094.
OpenAPI References
The https://swagger.io web site contains useful information for developers using REST APIs.
Graphics Key
The symbols in the following table apply to the graphics used in this guide.
Symbol Description
Simple element of a single type (for example, string, number, and so on).
You can access community and support information on RSA Link at https://community.rsa.com. RSA Link
contains a knowledgebase that answers common questions and provides solutions to known problems, product
Preface 6
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
l The appliance software version. This information is located in the top, right corner of the Quick Setup, or
you can log on to the Security Console and click Software Version Information.
The RSA Ready Partner Program website at www.rsaready.com provides information about third-party hardware
and software products that have been certified to work with RSA products. The website includes
Implementation Guides with step-by-step instructions and other information on how RSA products work with
third-party products.
Preface 7
RSA SecurID Access RSA SecurID Authentication API Developer's Guide
Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods 14
The RSA SecurID Authentication API is a REST-based programming interface that allows you to develop clients
that process multifactor, multistep authentications through RSA Authentication Manager and the Cloud
Authentication Service. The interface definition can be integrated with any programming language.
l Cloud Authentication Service. Your client must point to this server to support the RSA SecurID
Authenticate Tokencode, SecurID Token, Approve, Device Biometrics (such as Fingerprint), SMS
Tokencode, Voice Tokencode, and Password authentication methods.
l RSA Authentication Manager. The Authentication Manager server must be deployed in your environment
to support RSA SecurID tokens. Authentication Manager supports RSA SecurID Authenticate Tokencodes
when configured to integrate with the Cloud Authentication Service. The Authentication API supports
Authentication Manager 8.2 Service Pack 1 or later.
Note: Do not modify the rsa-securid-authenticate-api.yaml file. Modifying this file causes authentication to
fail.
The following diagram shows the general flow of the interface during authentication.
The following steps describe at a high level the client-server process flow during authentication. These steps
apply to both the RSA Authentication Manager server and the Cloud Authentication Service.
Calls to the Authentication Manager server use the user login ID (subjectName).
Calls to the Cloud Authentication Service use email or the SecurID Username specified in the Identity
Source configuration in the Cloud Administration Console. For Active Directory, the default is
sAMAccountName. For other LDAP vendors, this is a vendor-specific value.
Note: When the client sends Initialize with subjectCredentials, it provides the server with credentials to
be verified in advance. When subjectCredentials is not used, the server returns information to the client
indicating what credentials are required. subjectCredentials is optional for the Initialize call.
2. The Initialize interface responds with the challenge method options and requirements for the user to
complete authentication.
3. The client collects challenge method credentials from the user and sends them to the server in a Verify
interface call.
l If the user’s authentication is complete and successful, the user is granted access to the
requested resource.
l If authentication is not complete, the Verify interface sends the additional challenge
requirements the user needs to complete authentication.
Note: When a client (also called the agent) sends a multistep authentication request to the Authentication
Manager server, all steps in the transaction must be completed on the same primary or replica instance.
Note: The RSA SecurID Authentication API does not support user password change or device registration as
part of the authentication workflow. Users must perform device registration and manage their passwords prior
to initiating authentication with clients that use the API.
The Initialize and Verify interfaces return an AuthNResponse JSON object. The challengeMethods element in the
response is an array of one or more data elements the server requires to continue or complete an authentication
request. In many cases, this array contains a single item, but authentication clients should be able to handle the
return of multiple challenge methods and present those methods to the user.
The API supports the following multifactor authentication and mobile methods:
Future server releases might include new challenge methodIds, and clients should be ready to present these
new challenge methods in a dynamic manner.
A challenge method may or may not require the user to enter data, as described in the following table.
For elements that require the user to provide data, these mechanisms can help the client identify how the data
should be handled:
l Value Defined. The user enters a value that he will need to remember at a later time, such as a PIN or a
password. It is expected that clients require the user to enter the data twice and verify that both entries
match.
l Sensitive Data. When the user enters a sensitive value, the data entry should be masked or hidden if
possible.
The AuthenticationMethod and MethodPrompt elements contain the information the client can use to generate a
prompt for the authentication data and to perform some lightweight verification of the user’s entry. It contains
hints such as the minimum and maximum length of the expected data, the prompt that should be used for the
data, and the default value, if applicable.
It is important that the client sends authentication requests only to trusted servers. RSA recommends that you
configure the client to verify the server’s identity by validating that the SSL certificate presented by the server
has been issued by a root CA certificate, trusted by the client, directly or indirectly through one or more
intermediate CA certificates in the certificate chain.
RSA Authentication Manager generates a root CA certificate and SSL server certificates for each primary and
replica instance (server). The root CA is named RSA root CA for <primary-server-hostname>. Your
company can replace the console certificates with certificates signed by a different CA.
For the Cloud Authentication Service, use your browser to visit the Authentication API REST URL link, where you
can view and retrieve the root CA certificate that issued the certificate presented for that link.
RSA Authentication Manager uses the default port 5555. For example: https://<fqhn>:5555/mfa/v1_
1/authn/initialize. The Cloud Authentication Service uses the default port 443.
For the Cloud Authentication Service, add customerid.securid.com/ to each URL. For example,
customerid.securid.com/mfa/v1_1/authn/initialize, where customerid.securid.com is the Authentication
Service Domain for your deployment. Your Super Admin can find the Authentication Service Domain in the Cloud
Administration Console under Platform > Identity Routers on the Registration tab of the Identity Router
wizard.
Every call from the client requires a key to securely identify the authentication request. In the rsa-securid-
authenticate-api.yaml file this is the client-key. By default, the client-key is included in the HTTP header of
authentication requests. Your Super Admin needs to generate this key and send it to you securely.
If the Super Admin enables Hash-Based Message Authentication Code (HMAC) mode, the HTTP header value is
an HMAC calculated from the Access Key, a hash of the request body, the Access ID, and other request-specific
information. HMAC requires both the Access Key and Access ID. For more information see "Configure the RSA
Security Authentication API for Authentication Agents" in RSA Link.
The following table lists the supported MethodIDs for the RSA SecurID Authentication API.
Note: In this table, AM refers to RSA Authentication Manager and CAS refers to the Cloud Authentication
Service.
Attribute Data
Attribute Name Direction Description
Value Type
DEVICE_
NOT_
REGISTERED
METHOD_
NOT_
ENROLLED
After the Cloud Authentication Service receives an Initialize request from an authentication client, the server
determines which authentication methods to return to the client by evaluating the following factors:
l Assurance level (specified in a policy or by itself). See Assurance Level Evaluation below for a
description of this process.
l Verification of the primary authentication method. Users are challenged for primary authentication (for
example, username and password) when they initially attempt to access the application. After primary
authentication, the assurance level determines if additional authentication is required using RSA
SecurID, RSA SecurID Authenticate Tokencode, Approve, Device Biometrics, SMS Tokencode, or Voice
Tokencode.
The client might not require primary authentication. If it is required, the server might return different
results depending on whether primary verification succeeds.
l If the client's required assurance level or higher contains the primary authentication method in the list of
methods required for additional authentication, and if that method is satisfied during primary
authentication, the server does not return that method to the client.
For examples of server behavior, see Scenario: Assurance level does not include the primary authentication
method on page 17 and Scenario: Assurance level includes the primary authentication method on page 17.
Assurance levels define the authentication methods required to access applications. RSA SecurID Access
provides three assurance levels: High, Medium, and Low. Each level indicates the relative strength and security
of the authentication methods within that level. The Super Admin configures authentication options for each
assurance level. An option can be a standalone authentication method such as Device Biometrics, or it can
combine two methods connected by AND operators, such as SecurID Token and Approve.
The first option listed for an assurance level on the Assurance Levels page is presented as the default for each
new user when he or she authenticates to an application or client assigned to that assurance level for the first
time. A user can select another option at any time, as long as the assigned assurance level or a higher
assurance level contains additional options that the user can complete. When a user successfully authenticates
with an option, that option becomes the user's default for future authentications for that assurance level.
For more information on assurance levels, see "Assurance Levels" on RSA Link at
https://community.rsa.com/docs/DOC-53965.
When the Cloud Authentication Service receive an authentication request, it performs the following evaluation:
5. If primary authentication is not required, the server returns the remaining methods to the client. If
primary authentication is required, the server verifies the primary authentication method, then
determines which methods to return to the client as shown in the following scenarios.
The following table provides examples of expected server behavior during authentication when the default
option is available in the assigned assurance level or a higher level. The default option is moved to the top of the
returned list of challenge methods.
The following table provides examples of expected server behavior during authentication when the default
option is not available.
If the method list contains duplicates, the server removes the duplicate sets, as shown in the following example.
Original Methods List Containing Duplicates Methods List After Duplicate Removal
(SECURID AND TOKEN) OR
(SECURID AND SMS TOKENCODE) OR (TOKEN)
(SECURID AND SMS TOKENCODE) OR (TOKEN)
(SECURID AND APPROVE) OR (SECURID AND
DEVICE BIOMETRICS) OR (APPROVE) OR (APPROVE) OR (DEVICE BIOMETRICS)
(DEVICE BIOMETRICS)
If a method requires a device and the user has not registered a device, the method is included in the methods
list marked with the METHOD_NOT_APPLICABLE attribute and the value DEVICE_NOT_REGISTERED. The user
must register a device before using this method.
l If primary method verification is not required, or if it is required and authentication succeeds, the server
returns only the methods from the required assurance level or higher. It does not return the primary
method.
l If primary method verification is required and fails, the server adds the primary method to the list of
methods in the assurance level and returns all methods to the client.
The following examples illustrate this behavior. In the following table, the assurance level specifies
(DEVICE BIOMETRICS) OR (SECURID AND APPROVE).
1. The server attempts to validate the credential received from the client for primary authentication.
2. If validation succeeds, the server removes the primary authentication method from the list of methods in
the required assurance level or higher and does not return that method to the client. If validation fails,
the server adds the primary method to the list of methods in the assurance level.
3. The server eliminates any redundant methods and returns the remaining methods to the client, which
are required to satisfy the assurance level.
The following example illustrates this behavior. In the following table, the assurance level specifies (SECURID
AND APPROVE) OR (SMS TOKENCODE).
Cancel Call 39
Initialize Request
The Initialize request is the first call to the server. This call starts the authentication process.
Note: Make sure you obtain the necessary keys from your Super Admin. For details, see Required Keys for
REST Requests on page 12.
When you use Initialize without subjectCredentials, the server response tells the client which credentials are
required. When you use Initialize with subjectCredentials, the Initialize request provides the server with
credentials to be verified in advance. For more information, see Initialize with subjectCredentials on page 24.
The following graphic illustrates the relationships among the Initialize properties.
The following snippet shows a sample initialize request in Java. The client provides values for the variables in
italics.
initRequest.setContext(msgContext);
Unsupported Parameters
Do not include authnAttemptId with the Initialize call for either server. If provided, the server ignores it and
returns a new, random authnAttemptId in the AuthNResponse context property.
The following table lists unsupported parameters for each server. These parameters might be supported in
future versions of the RSA SecurID Authentication API.
The following table describes how Initialize and subjectcredentials works when sent to the Cloud Authentication
Service.
When the client sends Initialize with subjectCredentials to Authentication Manager, the client provides the
user's SecurID passcode in advance, before the server can return it as a challenge in a response. The caller can
complete a single-step authentication without multiple round-trips to the server. If the user's token is in New
PIN mode or requires the next tokencode to complete the authentication, calling Initialize with credentials still
results in a CHALLENGE response.
The following graphic shows the relationships among the properties for subjectCredential.
PASSWORD
methodId String Yes
SECURID
SECURID
A NameValue pair. The named methods are a
subset of those given in MethodIDs and
Attributes on page 13.
The following graphic shows the relationships among the properties for clientDetails.
Verify Request
Use the Verify interface to provide credential or confirmation values for challenge methods returned from a
previous Initialize or Verify call (authnResponseCode is CHALLENGE).
1. Sets the authnAttemptId field to the value returned by the server in its initialization response, in the
context field of the verification request.
2. Creates a new messageId and sets it in context.
3. Sets the inResponseTo field to the value of messageId returned by the server, in context.
4. For the challenge method returned by the server, collect the user’s credentials. Create a credential
object with user’s credentials in the collectedInputs field and method name in the methodId field. Add
the credential object to the subjectCredentials list of the verification request. If the server generated a
referenceID for this methodID, include the referenceID.
5. Invokes the verify call with a single credentials.
The following graphic illustrates the relationships among the Verify properties.
Property Description
Name must be the same as the credential methodId. This is the method ID of a challenge from a
name
previous call. For more information, see Initialize and Verify Response below.
The credential value entered by the end user, if applicable. This is the collected input value for
value AuthenticationMethodVersion with a valueRequired property of “true.” This can be null and any
value must be ignored if no value is required.
AuthNResponse Properties
Type
Parameter Description
Type
Parameter Description
l context (MessageContext)
l challengeMethods (ChallengeMethods)
The server returns the MessageContext.authnAttemptID in the Initialize response. The client must provide this
value in each subsequent response. Each server response also contains a random message ID
(MessageContext.messageId). RSA recommends that the client validate the MessageContext.inResponseTo
property returned by the server as specified in the rsa-securid-authenticate-api.yaml file. This value should
correspond to the messageId that the client provides in the prior Initialize or Verify call context property.
The following graphic illustrates the relationships among the AuthNResponse properties.
If the Initialize call contains credentials, the server response must indicate if the credentials are valid. This table
describes the content of the credentialValidationResults that can be returned from the Initialize call.
The challengeMethods describe information the user must provide or confirm to complete or continue the
authentication. The client must use elements from the challengeMethods to generate an authentication user-
interface.
An exception is when the caller provides credentials to the Initialize interface and no further credentials may be
needed. In this case, the challengeMethods must be empty. The server may respond with CHALLENGE even
when correct credentials are provided with the Initialize call. For example, the user’s passcode may be correct,
but the next tokencode may be required to complete the authentication.
The following graphic shows the relationships among the ChallengeMethods properties.
In the following graphic, ChallengeMethods returns two ChallengeMethodSets, requiring the client to satisfy
either two methods (Password and Approve) or one method (SecurID Token), as determined by the assurance
level for the access policy being used.
The following sections describe AuthNResponse content that may be returned from the Initialize and Verify
calls. Some section titles use an ellipsis to abbreviate the complete path to the element in the hierarchy. The
outermost property contains an array of ChallengeMethodSet objects.
Any one of these challenge methods can be satisfied to complete the authentication.
All authentication methods returned in the challengeMethodSet must be satisfied to complete authentication.
AuthenticationMethod returns details about data the user must provide to successfully complete authentication.
The server may return the priority, but because the versions array contains a single item, the client can ignore
this property.
AuthenticationMethodVersion returns details about data the user must provide to complete authentication.
The following graphic illustrates the relationships among the AuthenticationMethodsVersion properties.
AuthenticationMethodVersion provides data to the client on how the user should be prompted. The prompt
(MethodPrompt) object is returned.
VERIFY_
The server cannot handle the MISSING_
Undefi
ERROR initialize request. The request ATTEMPT_OR_ Undefined Undefined
ned
is malformed or invalid. MESSAGE_ID
No server cache
found for
attemptId:
Corrupt
message chain.
Got a
inResponseToI
D as: <xxx>,
but expected:
<yyy>
Possible
Access denied for this Populat Contains
reasons: Empty or populated
FAIL request. The user might have ed with challenge
ATTEMPT_ with results.
entered the wrong credential. IDs. sets.
TIMED_OUT
The authentication request is NO_ Populat
Empty or populated
SUCCESS complete without further CHALLENGES_ ed with Empty
with results.
challenge. REMAINING IDs.
Possible
reasons:
METHOD_
VERIFY_
FAILED_RETRY
METHOD_
Populat Contains
The authentication request VERIFY_ Empty or populated
CHALLENGE ed with challenge
requires further challenge. ERROR_RETRY with results.
IDs. sets.
METHOD_
VERIFY_
CHALLENGE
METHOD_
VERIFY_IN_
PROCESS
The server initiated the
authentication request, but
the request is not completed.
Contains
For such methods, server
challenge
creates and returns a
sets,
"referenceId" to the client.
Populat including the
Any subsequent/verify calls VERIFICATION_
IN_PROCESS ed with current IN_ Populated with result.
(from client) to poll the status PENDING
IDs PROCESS
of such method must contain
method with
the referenceId in the verify
its
request.
referenceId.
If a subsequent/verify call
(for a IN_PROCESS method)
Response to Verify
The server’s response to the verification request contains both the validation results of the last call to verify and
the remaining challenge methods of the current authentication attempt.
The validation results contain the response code of the current authentication attempt and a list of results of the
method verification from the last verify call. Each method verification result contains the method name and the
response code that indicates either success or failure.
The remaining challenges are what is required of the client to complete the current authentication attempt. In
the case of a successful authentication attempt, there should be no remaining challenge method.
The client can make an explicit call to check the status of the current authentication attempt. The response
contains:
Unlike the response to verify, the response of the status call does not include the list of the remaining challenge
methods or the list of methods that have failed in the current attempt.
The following graphic illustrates the relationships among the Check Status properties.
AuthNStatusReponse Properties
No verify or status calls can be made after this time (or if the
status check requests deletion of the attempt).
Cancel Call
Cancel Request
The client may send a Cancel request to cancel an authentication attempt at any point after the initialize request
has been sent. The Cancel request must provide the authnAttemptId string it received from the initialize
response. After a user's authentication attempt has been canceled, all previous authentication results are
discarded. The user must restart the authentication process.
The following graphic illustrates the relationships among the Cancel request properties.
The following example shows how a Cancel call provides the authnAttemptId to cancel an authentication
attempt.
{
"authnAttemptId":"106dd91f-22ab-4eec-92c8-a1a5e01b0da3",
"reason":"USER_ACTION"
}
Cancel Parameters
Default is USER_ACTION.
Sample client code for RSA Authentication Manager is available in the Extras.zip file in the directory \RSA
SecurID Authentication API.
This code demonstrates dynamically generating a Java client interface library from the OpenAPI YAML interface
definition. It includes two sample programs that use the generated interface to perform authentication.
The first example calls the interface and generates user prompts based on the challenges returned by the
server. It continues to prompt the user for challenges until the authentication succeeds or the authentication
attempt is halted. This example contains Java examples of generating the HMAC HTTP header value, if that
option is enabled at the server. It also configures the SSL client to validate the server's host SSL certificate.
The second example is a simplified example that provides a SecurID tokencode with the Initialize call to perform
a single-step SecurID authentication.
Software Requirements
The sample client has the following requirements:
You must also change your PATH environment variable so that both the Java SDK and Maven are included.
l pom.xml. Top-level Maven build file. Builds the client library and both client samples.
l README.TXT. Instructions for compiling and running the sample client.
l rest-java-client/. Dynamically constructs a Java client from the schema.
l rest-test-auth/. Sample interactive console-based authentication client. This client supports using the
Access ID and Access Key.
l rest-test-cli/. Sample command-line authentication client.
l openapi-yaml/rsa-securid-authenticate-api.yaml. Contains the OpenAPI interface definition source
(YAML) file. This contains details on the endpoints and JSON objects. Download the most recent file from
RSA Link at https://community.rsa.com/docs/DOC-71396.
The following procedure generates and compiles the client library, builds the test authentication client, and
builds the command line client for two sample clients that call RSA Authentication Manager.
l Meet the software requirements and obtain the necessary files. See Sample Client Overview on the
previous page.
l The Authentication Manager Super Admin must do the following:
l Provide the root certificate.
l Add a RESTful authentication agent to Authentication Manager
l Enable the API.
l Provide the Access Key value.
Procedure
1. Change to the directory where you extracted the OpenAPI REST Interface Source Example.
2. From the top level, run:
3. You need to generate or regenerate the Java Client library, rest-java-client. Change to the rest-java-
client directory:
cd rest-java-client
The pom.xml file in this directory also generates HTML documentation from the YAML file. This is
available in rest-java-client/target/generated-sources/swagger/index.html.
The pom.xml file also has a commented-out example of how a C++ library can be created.
cd rest-test-auth/target
cd rest-test-cli/target
Where:
accesskey. The Access Key provided by the server when the REST interface is enabled.
A property "authenticate.debug" can be set to "true" to enable debugging. For example, type: