We improved the invitation process by enhancing the handling of mobile number verification. If users haven't made any changes to their
mobile number during sign-up, they will no longer be prompted for re-verification.
We improved the error message when SMS code has expired in the Invitation Confirmation flow.
TOTP (Google authenticator) values that started with a 0 and contained an 8 or a 9 failed to validate. This has been resolved.
In some cases, when the event table was populated with many events, the Events page in the admin console failed to load. We optimized the queries used to select the Events. As a result, we no longer show how many events there are in total.
When an error occurred during migration process, it was always displayed in English. Now the correct translation is used based on user's locale.
We fixed a bug where Cookie based authentication did not work together with Action Token login
When a Single-logout endpoint is defined in the eHerkenning SAML metadata, and a single-logout request is initiated to the Onegini IdP, the end-user will see a confirmation page. After confirmation, the logout request to eHerkenning is opened in a new tab.
The ImportAPI now also supports coupling an account with an external IDP.
The Post Login Hook now also has information about the used login method, including action tokens. This allows implementors to take actions (e.g. STEP_UP) in the hook based on the loginMethodType used by the end-user.
We removed support for document-centric Identity Proofing via GBG.
To prevent disclosing if an account exists based on the Username and Password validation response time, we introduced a new configuration to set a minimum response time. When set, all log-in attempts take at least that time.
To prevent disclosing if an account exists based on the "Forgot Password"-flow response time, we introduced a new configuration to set a minimum response time. When set, all password resets take at least that time.
We added an optional feature that, when active, will not disclose that an account already exists during sign-up. This increases security but might reduce user-friendliness when a person tries to create an account with an email address already used by another account.
We fixed an issue where we logged-out users that used a web2app action token if they already had an active session. We now ensure that users that use a web2app action token will end up logged in for the user referenced in the action token.
We extended the UserInfoExtension to include the personId. This makes it possible for partners to implement a
password reset that can be triggered with the old username or any verified email address for non-migrated users.
Specifying a specific error message on the login page when a user cancels an iDIN transaction is now possible. The
message key is: personal.login.cancelled.user.message.
We now clear all the internal technical events which contain personal information when a user is deleted from the Onegini IdP. The functional events
remain as they do not contain personal information and or are required for audit purposes.
On the change password page, we now indicate that the user is using the wrong old password when they try to update their password with the incorrect "old
password" while setting their current password as the new one.
We fixed an issue where a Username and Password Identity Provider added on a partition prevented a password
from getting blocked (after X failed attempts).
We fixed an issue where it was impossible to reset a password if a Username and Password Identity Provider was
configured on a partition.
We fixed an issue where the email address or mobile number was not completely verified, when creating or updating these attributes via
the Person API or Import API with "verified" : true. This caused an Attribute verified
event during the first successful step-up. This event is now triggered directly after the attributes are modified via the API.
Fixed a bug where iDIN identification did not work correctly when a user omitted email and/or phone attributes at the iDIN issuer.
In the specific scenario where the user starts authentication via an external IDP at the Identity Provider page and is redirected to the Service Provider
(SP), the SP may try to execute a passive authentication request. If this request failed, the Single Logout feature did not work correctly.
Externally delivered step-up code has its own expiration time attribute now. Previously it used the one from Person Activation settings.
This attribute is configurable in the admin panel
and via the Configuration API.
We changed the user flow for SAML authentication requests (initiated by a customer portal). If the authentication with an external IDP fails, users are
redirected to the login page with an error message.
We made changes to our cache storage to improve performance.
We now allow end-users to delete their own account via the dashboard. This feature is off by default but can be activated (it requires a new template). This feature is required if you have an iOS app that offers account creation.
We now ensure a user completes the authentication (incl 2nd factor) before showing the email verification page for users that don't have a verified email address.
We made the activation URL for the Google Authenticator brand (partition) aware. Before, we showed the same issuer for all partitions, but now it can be
configured per partition. We also added the user's email address, which provides the end-user with more information on the accounts they added to their
The full user profile (not only the custom attributes) of the user are now also available in the DeliverExternalCodeExtension. For example, this extension is used to send an activation code via a letter or alternative email gateway.
In the authentication response, we now indicate which external IDP was used by the end-user to authenticate. E.g. when a user uses DigiD, we fill the <AuthenticatingAuthority> field with urn:com:onegini:saml:idp-alias:digid
It is now possible to break off the sign-up process by returning an error in the pre-creation extension point, even if the Force creating username & password during sign-up feature is enabled. For example, we use this process to make sure only existing (offline) customers can create an online account through an external IDP (e.g., DigiD).
The initials of a newly created account are now also available in the PersonCreationPreProcessExtension. For example, we use this to ensure an online customer is already known in an existing data store (e.g., CRM).
It's now possible to configure how many attempts a user has to verify an attribute (phone number or email address) before the code is invalidated.
Now an admin can configure if an end-user should verify their email address via a link (current behaviour) or a six-digit code sent to the email address. The latter option is more suitable for omnichannel services or organizations that built their own dashboard.
We now ensure that a user, who authenticated but did not finish or cancel the post-login hook, that decides to navigate back to the login page, will return to the post-login hook.
When using the Email gateway extension point, in combination with Persons partitioning we now also provide the partition_id to the extension.
This makes it possible for our partners to customize the sender or template based on the person's partition.
It is now possible to send SMS messages via our internal Messaging Service. This service makes it possible to build an integration to connect to an external (non-natively supported) SMS gateway via an API.
We now support iDIN authentication using the iDIN Login product type. Previously the Onegini IdP was always using the iDIN Identify product type.
We added a feature toggle to show the existing waiting page template. It should be enabled to improve the user experience when a step in the login process (e.g. due to processing time of the PersonPreCreateExtension) takes longer to finish. The feature is disabled by default.
When automatic linking is enabled, and automatic sign-up is disabled, we now also call the PersonCreationPreProcessExtension. This makes it possible to match not only on a user's email address but also on other attributes.
It is now possible to provide a validity time value for a specific externally delivered code (for activation & step-up) via the extension, the validity time configured in via a property (for step-up) or the admin (for activation) are now both the default and the max.
We fixed an issue where the user's last login time was not updated during a SAML ECP login (used for the OIDC ROPC flow in Token Server).
We fixed a bug where the CredentialAPI returned an error for end-users without an (optional) mobile number when Mobile number verification required was enabled. Now, only if the user has a mobile number in their profile, it must be validated.
We improved the way an HTML form is submitted. We now prevent the same form from being submitted shortly after the initial submit (e.g. when the user is double-clicking), which caused an error in the logs.
We now support changing the initial (unverified) mobile phone number after a verification code is sent out, in the scenario where Allow to set initial step-up method, and Mobile number verification required are both enabled.
We no longer throw an exception when illegal characters are used in a language parameter.
When an exception occurred in the Post Login Hook, the Onegini IdP did not handle it correctly. As a result, the Post Login Hook was not entirely executed. In the new situation, when an error occurs (e.g. a status 500), the end-user is logged out and has the reauthenticate.
In some SAML scenarios, the user was redirected to the dashboard, while the expected behaviour was that the user should be redirected back to Service Provider. We now make sure the user is redirected to the service provider.
A dependency upgrade caused problems with sending emails. We fixed that in this version.
We added a new configuration option for SAML based Identity Providers to support the ForceAuthn attribute, which allows you to explicitly indicate that the end-user must authenticate (again) at the external Identity Provider.
Template handling is now more secure, but also more restrictive. This might have impact on existing templates that have been customised. For more information, please read the Thymeleaf documentation on this change.