This article describes how to upgrade Smart ID Identity Manager from 23.10.3 to 23.10.5.

Internal user locking mechanism after failed login

Previously, the system locked internal users after 20 failed login attempts. With the 23.10.5 release, this mechanism has been extended to allow automatic unlocking of the user. You can configure this behavior, follow the instructions under Configure Internal profile in Set up authentication profile in Identity Manager.

With update_db the parameters are set as follows by default:

• Maximum failed login count: 3

• Automatic unlock mechanism: true

• Blocked user wait time: 300s 

Make NumberRange using isolated transaction

There is a change in which database transaction a NumberRange BPMN task participates. Previously, the outer transaction was used for the operation on the NumberRange tables.
This outer transaction also included the operations of the tasks before and after the NumberRange task, up to the usual transaction boundaries.

As of now, an own short transaction will be used for the few operations on the NumberRange tables. These database operations ensure that only the single NumberRange task is executed, and no other operations on the same NumberRange happens at the same time. There is no parallelism. In the past this was also true for the outer transaction. The NumberRange's locking statements also affected the outer transaction. As of now, the "there is no parallelism" will only be true for the NumberRange task itself.

This change has two consequences, that have to be considered:

• If there is an error in any of the following tasks, the outer transaction is rolled back. In the past, this rollback also "returned" the already taken number back to the NumberRange.
  As of now, a number taken from the NumberRange will not be automatically returned back to the unused numbers of the NumberRange in case of an error.
  If you want to put the already taken number of the NumberRange back, you can achieve that via a BPMN boundary event, that becomes active in case of an error.

• In the past, there was no parallelism in the tasks following the NumberRange task up to the next transaction boundary.
  As of now, the tasks after the NumberRange task can be executed in parallel. Make sure to double-check that the tasks after the NumberRange tasks do no harm if executed in parallel.

A positive side effect of this change is that more operations can happen in parallel and the overall performance increase.