Previous Topic: Step 2: ArcotID PKI AuthenticationNext Topic: Password Authentication

CA Strong Authentication Web Services Guide › Authenticating Users › Questions and Answers Authentication

Questions and Answers Authentication

The Question and Answer (QnA) authentication mechanism can either be used as a secondary authentication method for Step 1: ArcotID PKI Download, or Forgot Your Password (FYP) authentication, or can be used as an independent authentication type.

In this mechanism, the user can either set their own set of questions and answers during the QnA creation stage, or your application can choose to ask pre-defined questions to the user. The maximum number of questions to be set, the number of questions to be asked to the user, and the minimum correct answers to be collected during authentication are all configurable parameters and can be set by using the Administration Console.

This section walks you through the following topics for QnA authentication:

Preparing the Request Message

For QnA authentication, you must prepare the following request messages:

Fetching Questions

The GetQuestionsRequestMessage is used to fetch the questions from AuthMinder Server. 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 unique identifier of the user.

orgName

No

The organization to which the user belongs to.

fetchAnswers

Yes

The flag, which indicates whether to fetch the answers.

Following are the supported values:

  • 0: Indicates that the answers will not be fetched. Use this option, if you want AuthMinder Server to verify the answers.
  • 1: Indicates that the answers must be fetched.
    You must enable this option if QnA authentication is performed using the caller verification mode. This mode enables you to collect the answers from the user, verify the answers, and then send the verification result to AuthMinder Server.

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.

Verifying Answers

The VerifyAnswersRequestMessage is used to verify the answers provided by the user. 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.

orgName

No

The organization name to which the user belongs to.

qna

Yes

Contains the following information:

  • questionID
    The unique identifier of the question asked to the user.
  • answer
    The answer provided by the user.
  • verificationStatus
    Indicates whether the answer provided is correct or wrong.

    Note: The verificationStatus element is valid only if caller verification is enabled.

tokenType

No

The type of authentication token that is expected from AuthMinder Server after successful authentication. See "Verifying the Authentication Tokens" for more information.

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

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.

    Note: The additionalInput element is available at the end of the request message. You can add more than one of these elements.

Invoking the Web Service

The following procedure outlines the QnA authentication steps:

  1. (Optional) Include the authentication and authorization details in the SOAP header or in the additionalInput element of the GetQuestions operation. See chapter, "Managing Web Services Security" for more information on these details.
  2. Use GetQuestionsRequestMessage and construct the input message.

    Note: In the request message, you must set the fetchAnswers element, if you want to enable caller verification mode.

  3. (Optional) If you are implementing a plug-in, then invoke the additionalInput element type to fill the additional input.
  4. Invoke the GetQuestions operation of the ArcotWebFortAuthSvc service to retrieve the user’s questions and answers from AuthMinder Server.

    This operation returns GetQuestionsResponseMessage, which includes the questions to be asked, answers for each question, transaction ID, message, response code, and reason code.

  5. (Optional) Include the authentication and authorization details in the SOAP header or in the additionalInput element of the VerifyAnswers operation. See chapter, "Managing Web Services Security" for more information on these details.
  6. Use VerifyAnswersRequestMessage and construct the input message.
  7. (Optional) If you are implementing a plug-in, then invoke the additionalInput element type to fill the additional input.
  8. Invoke the VerifyAnswers operation of the ArcotWebFortAuthSvc service to verify the answers provided by the user. Optionally, you can also specify the token type that must be returned to the user after successful authentication by using the tokenType element.

    This operation returns VerifyAnswersResponseMessage, which provides the transaction details, credential details, and token information.

Interpreting Response Messages

Following are the response messages that are returned as part of QnA authentication:

Fetch Questions Response Message

For successful transactions, the response message, GetQuestionsResponseMessage returns the elements explained in the following table. 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.

Element

Description

qna

Contains the following question and answer details:

  • questionID
    The unique identifier of the question asked to the user.
  • question
    The question that has to be asked to the user.
  • answer
    The answer for the corresponding question to be asked.

transactionDetails

Contains the following transaction details:

  • message
    A string that defines the status of the operation.
  • reasoncode
    Unique code that is sent by AuthMinder Server if the operation fails.
  • responseCode
    Unique code that is sent by AuthMinder Server if the operation fails.
  • transactionID
    Unique identifier of the transaction.
  • additionalOutput
    The output for the additionalInput that was passed to AuthMinder Server.

Verify Answer Response Message

For successful transactions, the response message, VerifyAnswersResponseMessage returns the elements explained in . 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.