-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using the server's basePath when building the SAML ACS #51391
Conversation
@elasticmachine merge upstream |
💔 Build Failed |
💔 Build Failed |
Pinging @elastic/kibana-security (Team:Security) |
@elasticmachine merge upstream |
💔 Build Failed |
CI failure: |
ACK: reviewing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with green CI (once #51608 is merged). Sorry for introducing this bug and thanks a lot for fixing it!
@elasticmachine merge upstream |
💚 Build Succeeded |
* Using the server's basePath when building the SAML ACS * Fixing getACS call
Previously, we were using the request's basePath when building the ACS. This would cause the space prefix to be included when building the ACS. This isn't an issue when using
xpack.security.authc.saml.realm
, only when using the deprecatedxpack.security.public.*
settings.This was accidentally and indirectly fixed by #44513 because the even more complicated (but improved) SAML dance redirects the user to
/${serverBasePath}/api/security/saml/start
before starting the SAML authentication. However, I didn't want to rely on this incase something else changes.Resolves #51337
"Release Note: Resolving SAML bug when building the ACS when
xpack.security.public.*
settings are used and aserver.basePath
are configured"