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).
Feature | Version | Description and migration hints |
|---|---|---|
Default URL, Application entry URLs | 7.3 | Configuration of default URLs and allowed application entry URLs.  Migration hint Configured in Loginapp >> UI Settings >> Authentication Flow UI >> Target URI Resolver. |
ID propagation | 7.1 | Propagation of identity information using Identity Propagation plugins. Migration hint See property Identity Propagation in Loginapp >> Authentication Flows >> Target Application. |
Required roles | 7.1 | Require one or more roles in target application configuration. Migration hint In the Target Application configuration use the following plugins:
To check for multiple roles, use a Selection Step with the Abort Step in the options. The condition can be simply a Has Matching Role plugin. However, it may also be a combination of several conditions including Has Tag and logical operators. |
Airlock Gateway (WAF) Roles | 7.1 | Configure what roles (credentials) are used to authenticate the Airlock Gateway (WAF) session. Migration hint Use property Airlock Gateway (WAF) Mapping Roles (Credentials) in Loginapp >> Authentication Flows >> Target Application. |
Terms of Services | 7.3 | Enforce the acceptance of application-specific terms of services. Migration hint Use the Terms of Service Step in Loginapp >> Authentication Flows >> Target Application. |
URL-triggered step-up roles | 7.1 | Defines a list of roles that are required when starting application-triggered step-up. If the roles are missing in the session, a step-up is triggered. Migration hint Use two separate Authentication Flows (in different Target Applications): one with weak and one with strong authentication. Issue a tag after successful weak authentication (e.g. PASSWORD_VERIFIED). In the strong authentication flow, use this tag as a skip condition for the first authentication step. Applications calling IAM to trigger a step up (using an URL like |
Different username for application | 7.1 | Instead of propagating the username of the logged-in user, use an application-specific username from the user's context data. Migration hint Configured in the Username Providers property in the REST Identity Propagation plugin used in the Target Application configuration. |
Specific Access Policy | 7.3 | Rules to obtain new roles based on other roles and risk tags. Migration hint Use a dedicated authentication flow for the application. Use a combination of steps, selections, and conditions to derive roles and tags from given roles and tags. Example steps:
There is no 1:1 replacement for the application-specific access policy. Risk-based authentication is not yet supported in the Loginapp REST UI. |
Role processing | 7.3 | Add, delete, and transform roles for identity propagation. Migration hint Configured in the Role Providers property in the REST Identity Propagation plugin used in the Target Application configuration. |
User name transformation for ID propagation | 7.3 | Transform username before using it in identity propagation. Migration hint Configured in the Username Providers property in the REST Identity Propagation plugin used in the Target Application configuration. Username providers only allow to use of a different username stored in the user's context data. Other transformers like lower and upper case transformers or primary key lookup is not yet available and may be added in a later release (AI-13605). |
Different password for application | 7.3 | Some Identity Propagator plugins need the user password. This property allows using of a password from either the configuration or the user context data instead of the one the user entered. Migration hint Use features of existing Identity Propagator plugins. Some but not all Identity Propagator plugins support this feature by reading the password to be used from the user's context data. There is no password provider feature. |
Feature | Version | Description and migration hints |
|---|---|---|
List accessible target applications (AI-13610) | 7.5 | Show a list or grid of all accessible target applications, self-services, and other targets. Migration hint See documentation for the application portal in the Loginapp REST UI (available in the documentation of IAM 7.5 or later). |
List accessible self-services (AI-13609) | 7.5 | Show a list or grid of all accessible self-services. Migration hint See documentation for the application portal in the Loginapp REST UI (available in the documentation of IAM 7.5 or later). |
Application grouping (AI-13606) | 7.5 | Group applications and self-services. Migration hint See documentation for the application portal in the Loginapp REST UI (available in the documentation of IAM 7.5 or later). |
Feature | Version | Description and migration hints |
|---|---|---|
Intermediate pages | 7.1 | Custom intermediate pages are displayed between authentication and authorization and before forwarding to a specific target application. Migration hint Use the Acknowledge Message Step or a custom step (with a custom UI) in the authentication or authorization flow. |
Internal services | 7.4 | Require specific roles for internal services accessible to logged-in users. Migration hint The protected self-services are only accessible if the corresponding Access Condition and Authorization Condition are met. Example: Loginapp >> Protected Self-Services >> Airlock 2FA Device List >> Access Condition and Authorization Condition. |