You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a SP Initiated SSO, len(possibleRequestIDs) is not empty anymore.
If a few minutes later, when the cache of Request IDs has not expired, a user tries to log in with IDP Initiated SSO, that condition is not going to be true anymore and results in an Authentication failed error.
So I am wondering:
Why (and do we really need to) check len(possibleRequestIDs) in a first place?
Even if I invalidate the cache on the requests IDs as soon as the authentication succeed, there are still chances that this error happens in a concurrent scenario. If a user fails to authenticate to the IDP, the IDP initiated login won't work until the request ID of the user has expired in the cache.
edit: I'll need to check from my IDP if ResponseTo is actually empty when it's IDP Initiated - got me a doubt.
The text was updated successfully, but these errors were encountered:
When having both IDP Initiated SSO and SP Initiated SSO, the if condition does not match anymore:
https://github.com/crewjam/saml/blob/master/service_provider.go#L517
After a SP Initiated SSO,
len(possibleRequestIDs)
is not empty anymore.If a few minutes later, when the cache of Request IDs has not expired, a user tries to log in with IDP Initiated SSO, that condition is not going to be true anymore and results in an
Authentication failed
error.So I am wondering:
len(possibleRequestIDs)
in a first place?edit: I'll need to check from my IDP if ResponseTo is actually empty when it's IDP Initiated - got me a doubt.
The text was updated successfully, but these errors were encountered: