Bug 56451 - Keycloak Multiple Tab unexpected Login Behavior
Keycloak Multiple Tab unexpected Login Behavior
Status: NEW
Product: UCS
Classification: Unclassified
Component: Keycloak
UCS 5.0
amd64 Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2023-08-17 22:11 CEST by ageukes
Modified: 2023-09-01 13:45 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2023072421000262
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ageukes univentionstaff 2023-08-17 22:11:54 CEST
Bug Description:
When more than one tab is opened in the browser simultaneously, all redirecting to Keycloak (e.g., on browser startup with multiple start pages), and a user logs in on one of these tabs (which works without any issues), attempting to refresh any of the other tabs displays an error indicating that the user is already logged in.

Desired Behavior:
The users would like to suggest a modification to the current behavior. After a refresh, the authentication should be performed based on the existing session, and the user should be redirected back to the service provider instead of displaying an error. Alternatively, an automatic detection mechanism could be implemented where if a user logs in on one tab, all other tabs would be redirected back to the service provider as well. However, the users understand that this might require more complex adjustments.

Relevance of the Issue:
This issue remains relevant even as all technical team members primarily use Linux notebooks that are not joined to the domain, making Kerberos unavailable for all users. Therefore, the proposed adjustment would be beneficial in scenarios where Kerberos is not an option.

Steps to Reproduce:
Open multiple tabs simultaneously in the browser, all redirecting to Keycloak (this can also be achieved by opening two tabs without logging in first).
Example: Time Tracking and UCS Portal tabs.
Log in on the first tab (Time Tracking) and successfully authenticate, then redirect back to the service provider.
Attempt to log in on the second tab (UCS Portal) and encounter the error message stating that the user is already logged in.
Additional Observations:
This behavior occurs whether the login is performed using OpenID-Connect or SAML.

Comparison with Keycloak's Original Behavior:
After setting up Kerberos on a notebook, the users observed the following behavior in the original Keycloak instance (this information is intended for your reference; no action is needed on this front):
Interestingly, even with two simultaneously opened tabs, Keycloak attempts to authenticate in parallel, which is expected. However, this doesn't cause any issues.
Although two tickets for the SPN are requested in parallel, the authentication is successfully performed in both tabs using these tickets.

Browser Output (With Kerberos):
[Parent 2297: Main Thread]: D/negotiateauth   service = sso.siedl.net
[Parent 2297: Main Thread]: D/negotiateauth   using negotiate-gss
...
Following this, two tickets are obtained, as evidenced by the klist command output.

Conclusion:
The current behavior of Keycloak, where attempting to refresh a tab after logging in on another tab leads to an error, could be improved. The users propose this adjustment to enhance the user experience by allowing authentication based on existing sessions and seamless redirection to the service provider. The users are hopeful that this modification could be considered for future updates.