Cronto Approval Stealth Step
Cronto approval stealth step for public self-service flows.
This step displays a random dummy Cronto cryptogram and classifies any response OTP as wrong. Thus, it can never be successfully completed. It is intended to be used to avoid information leaking about users. Externally it behaves like the real Cronto approval step for public self-service flows.
This step is needed if the Cronto approval is used instead of a user verification step. Because the real Cronto approval step cannot be used for nonexistent or otherwise invalid users, a selection must be configured, using the "Public Self-Service Allowed Condition" to ensure that only users that are allowed to do public self-services enter the real Cronto step, while the other users end up in the stealth step.
Note that push and online validation have to be disabled in the real Cronto step, otherwise information would be leaked because it could behave differently for existing users (e.g. show push device selection). The configured authentication method ID must be the same as that of the real Cronto step. Also make sure the configured Flow Processors and Flow Restrictions in the public self-service flow allow nonexistent users and do not provide user feedback.
crontoHandler) Handles all Cronto-specific actions.
When the Cronto app communicates directly to IAM (for online validation and push notification management) these requests are on a separate session and must therefore be handled by a separate, global Cronto Handler defined in "Cronto App Communication" in Loginapp.
authenticationMethodId) Example: a system tracks two passwords per user. Password 1 is used in flow A, password 2 in flow B. These two steps must have distinct 'Authentication Method Ids', e.g. PASSWORD1 and PASSWORD2.
If only one identifier (e.g. "PASSWORD") is used, this may allow brute force attacks on the password as follows. Assuming an attacker knows the user's password 1, they get an unlimited number of attempts on flow B, as the 'PASSWORD' counter can repeatedly be reset to 0 by performing a successful login on flow A.To prevent such attacks, use two different counters by setting the authentication methods, for example, to PASSWORD1 and PASSWORD2, respectively.
maxResponseRetries) The number of times the user may enter a wrong response before the flow is aborted (and the challenge is deleted). If set to 0, only 1 attempt is possible for each challenge.
The purpose of this settings is usability. The failed attempts counter is always increased upon receiving a wrong OTP and the user is locked when the global failed attempts limit is exceeded.
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) 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.
A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.
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: CrontoPublicSelfServiceApprovalStealthStep
id: CrontoPublicSelfServiceApprovalStealthStep-xxxxxx
displayName:
comment:
properties:
authenticationMethodId: CRONTO
crontoHandler:
customFailureResponseAttributes:
customResponseAttributes:
dynamicStepActivations:
interactiveGotoTargets:
maxResponseRetries: 3
onFailureGotos:
preCondition:
requiresActivation: false
skipCondition:
stepId:
tagsOnSuccess: