Unlock User Step (Public Self-Service)
This step unlocks a user in the following cases:
- No 'Max Number of Unlocks' limit is configured in the 'Public Self-Service Flow Settings' configuration
- The 'Max Number of Unlocks' limit configured in the 'Public Self-Service Flow Settings' has not yet been exceeded by the current user.
Note that in general, locked users are not allowed to perform a public self-service, unless custom restrictions are configured to allow public self-services for certain locked users (see Locked User Restriction). If this step is performed by a locked user, his failed logins for the configured authentication methods are reset. Otherwise, the failed logins are not reset.
Security Notice 1: This step should be the last step in the flow and must always come after at least one credential check step (e.g. email OTP). Precondition tags can help ensuring that only users that successfully completed a previous step are unlocked.
Security Notice 2: Automatically unlocking users can have unexpected security implications. Unlocking users that are locked for any reason other than too many failed password attempts is potentially a security risk, as it might allow brute-force attacks on the second authentication factor.
Security Notice 3: If users are unlocked with proof of only one verified factor, the number of unlocks must be limited in the 'Public Self-Service Flow Settings' plugin configuration. Otherwise bruteforce attacks on one factor are possible, lowering the security of a two login-factor setup to a similar one as a one-factor setup.
resetFailedLoginsForHtmlLoginapp) failedAttemptsCountersToReset) 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: PublicSelfServiceUnlockUserStep
id: PublicSelfServiceUnlockUserStep-xxxxxx
displayName:
comment:
properties:
customFailureResponseAttributes:
customResponseAttributes:
failedAttemptsCountersToReset: [PASSWORD]
onFailureGotos:
preCondition:
requiresActivation: false
resetFailedLoginsForHtmlLoginapp: false
skipCondition:
stepId:
tagsOnSuccess: