Token self-service features
17.5.5.5. Token self-service features (JSP-Loginapp migration)

The following table provides information about the availability of JSP-Loginapp features in the Loginapp REST UI and high-level migration hints (where available).

Information about the availability of upcoming releases is indicative and subject to change.

Please note the additional information on discontinued functions (see link below).

Version information about features not yet available will be updated or clarified as soon as known.

Note that the specified release versions are indicative and subject to change.

The following notation is used to indicate release versions (examples):

  • 7.7: planned for IAM 7.7
  • > 7.7: planned for an IAM release after 7.7
  • >= 7.7: planned for IAM 7.7 or later

Airlock 2FA self-services

Feature
Version
Description and migration hints
Airlock 2FA token migration
7.3
Migrate to Airlock 2FA as 2nd factor during the login process.

Migration hint

Use the following steps for token migration in the authentication flow:

  • Airlock 2FA Activation Step
  • Airlock 2FA Device Edit Step

Note that all other Airlock 2FA related self-services were not available in the JSP-Loginapp and are therefore not listed here.

mTAN/SMS self-services

Feature
Version
Description and migration hints
mTAN number registration with IAK
7.3
Register a phone number in the login process after verifying the username, password, and an IAK (initial activation key).

Migration hint

Use a Selection Step in the authentication flow with a Logical AND condition with the following sub-conditions:

  • Active Authentication Method for authentication method MTAN
  • Logical NOT of the Has mTAN Token condition
  • Has mTAN Activation Letter condition

Then use the following steps in the corresponding sub-flow:

  • User Data Edit Step to enter phone number
  • MTAN Verification Step with IAK verification enabled
  • Apply Changes step
mTAN registration: Allow phone number change
7.3
Configure whether an already stored phone number can be changed or not during mTAN token registration.

Migration hint

Use the mTAN token self-management features (protected self-service flows) instead.

The suggested solution is available only for logged-in users. The user must therefore first log in with the existing phone number and can then change the phone number in the mTAN token self-management.

Token migration to mTAN
7.3
Migrate to mTAN as 2nd factor during the login process.

Migration hint

Use the following steps for token migration in the authentication flow:

  • mTAN Token Registration Step
  • mTAN Verification Step
  • Apply Changes Step

To show a confirmation page, use an Acknowledge Message Step with a corresponding Custom Step UI in the token migration sub-flow.

Token migration: phone number normalization
7.3
If enabled, the entered phone number is normalized before being validated and stored.

Migration hint

The normalization feature is always on and cannot be turned off.

Token migration: phone number validation
7.3
Check if a valid phone number was entered by the end-user.

Migration hint

In the mTAN Token Registration Step configure one or more validators in property Validators On Normalized.

mTAN token self-management
7.4
Management of registered phone numbers for authenticated users. This includes adding new numbers, deleting numbers, changing existing numbers and labels. Phone numbers may be masked.

Migration hint

To enable the self-service and display the list of registered numbers, configure

User Self-Service Settings >> mTAN Number List.

To enable and configure the single self-service actions (add, edit, delete) configure one or more of the following plugins in the list of Protected Self-Service Flows:

  • Default mTAN Token Registration Flow
  • Default mTAN Token Edit Flow
  • Default mTAN Deletion Flow

As an alternative to the above-mentioned default flows, you may manually configure each flow as a list of steps using a Self-Service Flow plugin. As a starting point, please refer to the plugin documentation to see what flow it uses internally.

mTAN token self-management: Authenticate old phone number
>= 7.7
If changing an existing phone number, also verify the old number by sending an OTP to it.
mTAN token self-management: phone number normalization
7.4
If enabled, the entered phone number is normalized before being validated and stored.

Migration hint

The normalization feature is always on and cannot be turned off.

mTAN token self-management: phone number validation
7.4
Check if a valid phone number was entered by the end-user.

Migration hint

In the mTAN Token Registration Step configure one or more validators in property Validators On Normalized.

Cronto self-services

Feature
Version
Description and migration hints
Token migration to Cronto
7.3
Migrate to Cronto as 2nd factor during the login process.

Migration hint

Use the Cronto Activation Step in the token migration in the authentication flow.

Push activation
7.3
Activate push notifications (only required for CrontoSign Swiss).

Migration hint

Use the CrontoSign Swiss Push Activation Step and, if necessary, the condition CrontoSign Swiss Push Activation Possible.

Cronto token self-management (AI-13540)
7.5
Add, remove, and rename Cronto tokens for logged-in users.
Cronto token self-management: order activation letter (AI-13541)
7.5
Users may order new activation letter in token self-management.
Token migration: user may order a new activation letter (AI-13529)
7.5
Users may order a new activation letter in token migration flow.
Cronto reset self-service (ALIAM-13457)
7.5
Users can delete all registered devices during login. Optionally, another 2nd factor is used to secure the service.

Other token self-services

Feature
Version
Description and migration hints
Token Migration Hint Page
7.3
Page informing user about possible or enforced migration to new 2nd factor.

Migration hint

Use the Migration Selection Step in the authentication flow.

Token Migration Hint Page: multiple next auth methods
7.3
Offer multiple migration options when migrating.

Migration hint

Use the Migration Selection Step in the authentication flow. The selection conditions may result in multiple possible 2nd-factors to migrate to.

OneSpan Digipass activation (AI-13544)
only on request
Token activation of OneSpan (Vasco) Digipass OTP tokens.
Migration to Kobil TWV (AI-13546)
only on request
Migration from another 2nd factor to Kobil TWV during login. The token registration either displayed a code or orders an activation letter.
Kobil token self-management (AI-13547)
only on request
List, add, remove, lock, and unlock Kobil devices.

Note that all other Airlock 2FA related self-services were not available in the JSP-Loginapp and are therefore not listed here.