IdStory Identity Manager

Please add some UC, screenshots, anything that will help identify the problem on your project.

There is one transaction with changes that isn't definitely from same modifier

Maybe possible hit is run some planned task from scheduler and then run another task (bul operation). When both tasks will use same task thread result may be same. Try it!

Locally, I can simulate one scenario where there is a wrong user in the audit record.

User A starts activating 10 identities. At the same time, User B starts the same operation for another 10 identities.

The resulting audit will contain audit records for the same transaction, where the second user will be the modifier.

After deeper debugging, this issue is tied to provisioning only. In this case, only the VsRequest records that are generated within separate threads (futureTask) are incorrect.

So far, I haven't been able to resolve this issue. One possibility is the problematic use of the MODE_INHERITABLETHREADLOCAL strategy in an environment where pools are used. However, using MODE_THREADLOCAL in combination with DelegatingSecurityContextRunnable did not help.

The result of the debug is: The SecurityContext is set correctly when the thread is started. The problem only occurs in the IdmAuditListener / AuditableEntityListener, where there is already another user for the same thread.

I found solution for second scenario, where same transaction ID was use in another action.

It looks like, the main problem was in using of InheritableThreadLocal<TransactionContext> for combination with a pools. I implemented DelegatingTransactionContextRunnable for propagate the transaction context to child threads.

Now it works, but I need to more testing it.

I fixed both scenarios (I hope).

First:
It looks like the instance of Security context was shared betweed more threads. If SecurityService.setAuthentication method was called, then the contex was changed, but same instance was use in old threads too (Delegation wrapper dosesn't clear the context). As result name of logged user was changed in more then current thread.
I fixed that with call SecurityContextHolder.clearContext() in SecurityService.setAuthentication method.

Second:
It looks like, the main problem was in using of InheritableThreadLocal<TransactionContext> for combination with a thread pools. I implemented DelegatingTransactionContextRunnable for propagate the transaction context to child threads.

This fix needs more testing and consultations. This is the reason why I commited this fix to the 10.5.0 instead to the hotfix.

Commit: https://github.com/bcvsolutions/CzechIdMng/commit/47d33033b97e29ba9e74be6f67e10cdd135324c4

I did test and code review, it's awesome! I did not found a broken UC.