Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Some SAML flows will fail when several tabs of the same browser window initiate them in a quick succession/simultaneously #41
CentOS 7.4, gluu-server-3.1.2-1-4.centos7
Steps to reproduce:
In case you have setup conforming to the item 4) of "Preconditions" (all steps needs to be done relatively quick, otherwise some expiration timer may run out):
If it's too troublesome to create the complete Inbound SAML setup, it's possible to mimic required conditions with the following trick (it also presents another variation of triggering this issue at the same time, showing how else it may degrade user's experience):
In the case when Inbound SAML is used as described, the 2nd flow will fail after browser is redirected back to IDP's
Apparently it has something to do with how IDP or our customized RemoteUser handler handles stale auth requests/repsonses/sessions. After the first request is fully processed, a subsequent ones which were initiated very soon after it, but which responses are already "late" when they reach Gluu instance in question, are being dropped with no mitigation procedure in mind, possibly resulting in a bunch of tabs "stuck" in different erroneous states (there was a report from a customer who was inconvenienced by it)
If several pages were reloaded or loaded at once, initiating a bunch of (almost) simultaneous SAML signin flows (which is a common case when a browser is launched and a previous session is restored, or a "Reload all" button is used etc), after the very first request resulted in sessions created at oxAuth and IDP, when other (now stale) response from 3rd party services used for authentication will reach oxAuth/IDP, they should be silently discarded, and user's flow should be continued as if he was successfully authenticated in the end, returning him to the intended SP's which sent him here.
We also would really need a backport of this fix to 2.4.4 codebase (a customer wants the fix for their live 2.4.4 setup). Reproduction steps for this package are effectively the same (I used Asimba setup there instead of Passport-SAML). Logged messages are different there, though similar in nature, full log is here, a short excerpt is below:
I've changed issue type from "bug" -> "enhancement". I'm not sure that is really Gluu issue. We not changed Shibboleth IDP code. We are using their binaries. During packaging we only add Filters to intercept RemoteUser endpoint calls to allow us redirect to oxAuth for authentication.
Hence before start to work on this issue we need to test if SP + Shibboleth IDP without Gluu. If ther flow the same we can offer to open Shibboleth issue.
@aliaksander-samuseu can you try to reproduce this issue with SP + Shibboleth IDP without Gluu changes.