Dmitry Telegin

As for workaround, the only viable option at the moment seems to be deploying a custom `TokenExchangeProvider` that would override `exchangeClientToClient()` and bring in the old (pre-18) behavior. @ActJV @Mica4DEV...

Thanks @elf-pavlik , that makes absolute sense, though things could a bit more complicated with Client IDs. > While Client ID documents can be cashed, their identifiers and not managed...

> I disagree. This is how a client can indicate that DPoP is required rather than opt-in on the part of a client. It is correct that we need to...

@ahus1 so, you're suggesting that we split this issue into two: * use `ClusterAwareScheduledTaskRunner` for LDAP sync in order to avoid concurrent runs (bug/defect); * develop a mechanism to ensure...

Actually, the code that guards from the concurrent runs is already in place: https://github.com/keycloak/keycloak/blob/c9f38d36a97764dc161b6126eb8eff24b3c9a1c1/model/storage-private/src/main/java/org/keycloak/storage/managers/UserStorageSyncManager.java#L138-L175 Though I'd say it's a bit cumbersome as it uses an hierarchy of nested tasks (`UserStorageSyncTask`...

@vkorpi I've tried to reproduce the network outage scenario; the user gets deleted and then recreated with the original ID and group / role membership. Is it the same for...

@vkorpi I have been able to reproduce this issue too. However, with network outage it seems to be different. Here's what I've tried: * set up OpenLDAP, created schema and...

After some research I can state that we have two separate issues here: 1. An exception is thrown during LDAP query. This could be caused by network disruption or misconfigured...

Thanks @pravsjv for your investigation! > LDAPQuery.java return null List in both the cases when LDAPQuery fails and as well when the user is not present in the federation. Luckily,...