Verifying Password Type Credentials

CA Strong Authentication Web Services Guide › Authenticating Users › Verifying Password Type Credentials

Verifying Password Type Credentials

The authentication requests that are presented to the AuthMinder Server must specify the type of credential that has to be used to process the requests. In case of RADIUS and ASSP authentication requests, the input requests do not have the provision to specify the type of credential, and by default RADIUS uses One-Time Password and ASSP uses password credential for authentication.

To support any password-based authentication mechanisms for RADIUS and ASSP, or to map any input request with an unknown credential type to a particular password-based authentication mechanism you must create the Credential Type Resolution configuration. You can map the input request to any of the following credentials that AuthMinder supports:

Password
OTP
OATH OTP
ArcotID OTP-OATH
ArcotID OTP-EMV
RADIUS OTP
LDAP Password
Native Token

If a particular input request uses the credential resolution configuration, then the VerifyPlain operation is invoked to process that request. Based on the configuration, the incoming user credential will be mapped to the credential that it is configured to.

Note: To use this feature, you should have configured the created credential type resolution, as discussed in chapter, "Creating Configurations".

This section walks you through the following topics for verifying any password type credential:

Preparing the Request Message
Invoking the Web Service
Interpreting the Response Message

Preparing the Request Message

The VerifyPlainRequestMessage is used to verify any password type credentials that AuthMinder supports. The following table lists the elements of this message.

Element	Mandatory	Description
clientTxnId	No	Specifies the unique transaction identifier that the calling application can include. This identifier helps in tracking the related transactions.
userName	Yes	The name of the user whose credentials have to be verified.
orgName	No	The name of the organization to which the authenticating user belongs to.
password	Yes	The mapped password type credential with which the user has to be authenticated.
tokenType	No	The type of authentication token that is returned to the user after successful authentication.
additionalInput/pairs	No	AuthMinder’s additionalInput element enables you to set additional inputs if you want to augment AuthMinder’s authentication capability by specifying additional information. In such cases, you need to set the extra information in name-value pairs. name (The name with which you want to create the key pair.) value (The corresponding value for name.) Note: You can add more than one of these elements. Some of the pre-defined additional input parameters include: AR_WF_LOCALE_ID Specifies the locale that AuthMinder will use while returning the messages back to your calling application. AR_WF_CALLER_ID This is useful in tracking transactions. You can use session ID or client transaction ID (clientTxnId) for specifying this information.

Invoking the Web Service

To verify a password type credential:

(Optional) Include the authentication and authorization details in the SOAP header or in the additionalInput element of the VerifyPlain operation. See chapter, "Managing Web Services Security" for more information on these details.
(Optional) If you are implementing a plug-in, then invoke the additionalInput element type to fill the additional input.
Use VerifyPlainRequestMessage and construct the input message.
Invoke the VerifyPlain operation of the ArcotWebFortAuthSvc service to verify the user’s credential.
This operation returns VerifyPlainResponseMessage, which provides the credential and transaction details.

Interpreting the Response Message

For successful transactions, the response message, VerifyPlainResponseMessage returns the elements explained in Verify Signed Challenge Response Message in Step 2: ArcotID PKI Authentication. These elements are included in the SOAP body. If there are any errors, then the Fault response is included in the SOAP body. See appendix, "Error Codes" for more information on the SOAP error messages.