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.
The Post Login Hook now also has access to
the SAML Custom Parameters. This allows us to take actions in the hook based on the provided
parameters in the Authentication Request.
The Post Login Hook now also has access to the IP address of the user that initiated the request. This allows us to
take actions in the hook based on the user's IP address.
The Post Login Hook is now triggered after the user reaches the required authentication level, while before, it was
triggered after the first factor was successful.
We now allow more IdP types from Token Server/Access for mobile app enrolment.
We adjusted the PersonAPI to match our documentation, all address fields are now optional. We removed the validation
that ensured some fields had to be provided as a set.
When an email address is removed in the Post Login Hook we now also remove that attribute as a username.
We introduced a generic approach for all emails to prevent URLs to be invalidated by some email clients and/or anti-spam software.
A user will be logged out of their account and redirected to the login page when they use a wrong password too many times while changing their password via
the dashboard.
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.
It's now possible to use the sms.sender.id custom message to change the (alphanumeric) sender of SMS messages per language variant (used for person partitioning).
We added the user's anonymized email address to the verify-email page, which can be displayed on this page for every scenario.
We now invalidate the code in the reset password SMS after a user successfully uses it. This results in a SmsPasswordResetCodeBlockedEvent event on the timeline.
Error messages weren’t available on the next screen if a user encountered a redirect. We now carry these messages over to the next page.
It is now possible to use an externally delivered code as an alternative step-up authentication method.
This enables users to regain access to their account, especially when they lost access to their primary 2nd factor. The externally delivered code requires
an extension that has a way to deliver the code to a user (e.g. via a letter).
The Externally Delivered Code Step-Up method is now set as the preferred one when there is a code active.
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
authenticator.
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.
We fixed an issue with iDIN after migration to centralized session management.
We have fixed a bug in the email verification page where we did not show the result when an unauthenticated user used the email verification link for a second time.
In the scenario where the external IDP linking failed, e.g. when it was already linked to another account, we still synced some attributes. We now do that only after successful linking.
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.