Repository navigation
Replies: 1 comment 4 replies
|
This seems like the correct functionality. Since the admins have updated the flow, the new one should be enforced, so failing the authentication flow immediately for users in the process of authenticating seems like the safest approach. The only reasonable approach that would allow continuing the ongoing process would be to attempt to evaluate differences between the old and new flow, but this would require introducing some non-trivial functionality (which could introduce security issues) for a process that normally only affects a small number of users. The best way to reduce the impact in this case would be to introduce such changes when there is a small number of authenticating users. Additionally, if this process only affects users who are actively authenticating at the time, increasing the SSO timeout can also reduce the number of simultaneous logins and, thus, affected users. |
thanks @darius-m. Yes. This process only affects users who are actively authenticating at the same time. Could you clarify how can increasing SSO timeout can help here? |
|
I'm refering to the SSO session timeout - that is, the time the SSO session remains active before the user is asked to log in again (I hope I didn't butcher the names). A longer session means that user logins will happen less often (as the SSO will reuse the existing session if one is valid). |
|
Yes @darius-m. This may solve half of the problem but we can not solve it fully. Looks like it's a limitations of KC. Also we have observed that realm local cache may take sometime to refresh in all instances in case of multi replica setup. |
|
While I'm not a developer of Keycloak, so I'm not entirely sure whether it is intended, this to me seems like the correct implementation, not a limitation of Keycloak. Any changes to an authentication flow should result in restarting ongoing authentications. For example, think of a scenario where you change an OTP subflow from "Conditional" (if configured) to "Required". In that case, should the ongoing flow enforce OTP (and, if required, set it up) or allow the user to continue without OTP (if OTP was not previously configured). According to the new flow, which Keycloak should enforce, it should be "Required", but it isn't according to the flow the user had started. This also extends to changing the flow with a different one, even if it is functionally identical to the old one, as Keycloak would have to run a sort of "diff" between the ongoing (previous) flow and the new one and determine whether the user's authentication can continue or not. Implementing such functionality would likely add quite a bit of complexity to the code (and introduce possible vulnerabilities), for a scenario that rarely affects users. |
Uh oh!
There was an error while loading. Please reload this page.
When we modify the top-level authentication flow binding in Keycloak, any user who is currently in the middle of a multi-step login process will experience a login failure. The login succeeds for users who initiate a new request after the flow binding has been updated.
Steps to Replicate:
Request:
Is there a recommended method within Keycloak to prevent user login failures when authentication flow bindings are changed?
Thanks!
All reactions