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 |
|---|---|---|
Secret questions provisioning | 7.3 | Ask for answers to secret questions after login (if not enough answers are stored). Secret questions are used in the password reset self-service to verify the claimed user identity.  Migration hint Use the Secret Questions Provisioning Step in the authentication flow. The step provides fewer configuration options than the implementation in the JSP-Loginapp. |
Client certificate authentication (AI-13465) | 7.3 | User authentication based on verification of X.509 client certificates used in TLS handshake. Migration hint Use the one-shot feature in the IAM Loginapp. An integration in the Loginapp REST UI is not planned. The one-shot feature does not provide exactly the same possibilities as the implementation in the JSP-Loginapp did. |
Front-side Kerberos (AI-13467) | >= 7.7 7.3 (one-shot) | Front-side Kerberos user authentication. Migration hint Use the one-shot feature in the IAM Loginapp if possible. The one-shot feature does not provide exactly the same possibilities as the implementation in the JSP-Loginapp did. It is especially not yet combinable with 2nd-factor authentication or complex ID propagation mechanisms. Direct support in the Loginapp REST UI may be added later if requirements cannot be met with the one-shot feature. |
SSO Tickets (AI-13470) | 7.5 (7.3) | Authentication using SSO Tickets (e.g. JWT tokens) in URL parameters. The Loginapp REST API already supports the SSO Ticket Authentication Step with IAM 7.3. Additionally, in IAM 7.5, the SSO ticket can be used as GET parameter sso in calls of the following form:
Note that the GET parameter name sso is no more configurable. 3rd party systems may need to be adapted to call the new URLs and/or use the correct GET parameter name. |
SSO Ticket Identity Propagator | 7.5 | Add SSO Ticket to URL and redirect to target application. |
MSOFBA support (AI-15773) | 7.7 | Support for old HTTP clients used in MS Office applications to use MSOFBA (Microsoft Office form-based Authentication). Limited MSOFBA Support in Loginapp REST UI Note that the MS-Office applications (e.g. Word) use outdated browser libraries (IE11 or IE8) that are not compatible with the AIrlock IAM Loginapp REST UI. The Loginapp REST UI provides a very limited set of features available for MS-OFBA by offering a separate Loginapp front-end written in JavaScript. Currently, only password authentication and mTAN as the second factor are supported. If Microsoft does not update to newer browser libraries, MS-OFBA support may be removed from Airlock IAM in future versions. |
Feature | Version | Description and migration hints |
|---|---|---|
Role-based access control | 7.1 | Access control based on user- and acquired roles. 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. |
Static roles | 7.3 | Grant statically configured roles after authentication for ID propagation. Migration hint Use plugin Static Roles in Target Application >> Identity Propagation >> REST Identity Propagation. |
User-specific role timeouts (AI-13472) | 7.6 | Set role timeouts based on user-specific data. This allows choosing the value for role timeouts per user. |
Feature | Version | Description and migration hints |
|---|---|---|
Lock account | 7.1 | Lock account after n authentication failures. Migration hint In the Loginapp REST UI counters are managed for each authentication factor independently. This is absolutely necessary for security reasons because flow-based authentication schemes offer many more possible authentication flows. The maximum number of failed logins before an account is locked is configured here: Loginapp >> Authentication Flows. |
Temporary locking | 7.4 | Temporarily lock the user account after a series of failed authentication attempts. The lock period depends on the configuration and the number of failed attempts. Migration hint The Temporary Locking settings can be configured in Loginapp >> Authentication Flows Temporary locking must be enabled in each Authentication Flow (check box Enable Temporary Locking). While an account is temporarily locked, the web UI of all loginapp screens is blocked on the corresponding session such that no user interaction is possible. The end of the lockout period is displayed to the end-user. |
Show remaining attempts on login page | 7.4 | If configured, show the number of remaining attempts until locked. Migration hint To enable the feature check the Add Remaining Attempts Info box in the Authentication Flow plugin. |
Client fingerprinting lockout (AI-13473) | 7.7 | Lock accounts based on client fingerprinting value passed by Airlock Gateway (WAF). |
Feature | Version | Description and migration hints |
|---|---|---|
User representation (AI-12122) | 7.5 | An entitled user may access applications with the identity of another user. Migration hint The representer and the representee side may be upgraded independently. See User representation for further information. Note that custom implementations of |