FIDO Transaction Approval Step
Step to approve a transaction with FIDO.
To achieve dynamic linking of transaction parameters with the challenge sent to the FIDO authenticator, the transaction parameters are hashed together with a random nonce to generate the challenge.
Challenge C:= Hash(T | N), where:
Hashis the SHA512 hashing function.Tis the serialized form of the transaction parameters.Nis a random nonce to prevent replay attacks.
FIDO approval does not allow verification of the data via a separate channel. If this additional level of security is required, use other approval factors like Airlock 2FA, Cronto or mTAN.
onFailureGotos) If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.
This step can return the following error codes:
FIDO_AUTHENTICATION_FAILED: The FIDO authentication failed for unspecified reasons (either in the browser/client or during server-side verification).FIDO_AUTHENTICATION_TIMEOUT: The response from the browser/client has timed out.FIDO_AUTHENTICATION_ABORTED: The authentication has been aborted in the browser/client.FIDO_AUTHENTICATION_NOT_ALLOWED: The browser/client did not allow authentication with the given credentials.FIDO_WEB_AUTHN_NOT_AVAILABLE: The client/browser is not capable of performing WebAuthn/FIDO authentication.NO_VALID_TOKEN: The user has no eligible FIDO credential registered.
verificationLogging) This option enables logging of all relevant data to allow cryptographic verification of the dynamic linking as described in the plugin documentation. The information is logged on INFO level and can be found using the search term 'FIDO Dynamic Linking Verification Data'.
When enabled, the following information is logged as a JSON object:
- N: Nonce which adds randomness to the challenge to prevent replay attacks
- T: Transaction data map formated as a JSON String
- CAD: Challenge authenticatorData - Randomness added by the FIDO key during signing
- CCD: Challenge clientDataJSON - Object with challenge required by FIDO key during signing. Contains at least 'type', 'challenge' and 'origin'.
- S: Signed challenge returned from the FIDO key
- P: Public Key used during the challenge response protocol
The verification script has to check the following two properties to link the transaction data to the challenge:
- VERIFY(P, CM, S), where CM := CAD + SHA256(CCD) as defined by FIDO webauthn.
- CCD contains C, where C:= SHA512(T | N) as defined by Dynamic Linking on IAM.
A verification script can be downloaded from the Airlock IAM customer documentation
fidoSettings) interactiveGotoTargets) dynamicStepActivations) skipCondition) If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.
preCondition) requiresActivation) tagsOnSuccess) stepId) customResponseAttributes) A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.
Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.
Custom attributes are not returned for 'retrieve' endpoints.
customFailureResponseAttributes)
type: FidoTransactionApprovalStep
id: FidoTransactionApprovalStep-xxxxxx
displayName:
comment:
properties:
customFailureResponseAttributes:
customResponseAttributes:
dynamicStepActivations:
fidoSettings:
interactiveGotoTargets:
onFailureGotos:
preCondition:
requiresActivation: false
skipCondition:
stepId:
tagsOnSuccess:
verificationLogging: false