Skip to content
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

[Breaking change] Drop /api/security/v1/saml route in favour of /api/security/saml/callback #81733

Open
azasypkin opened this issue Oct 27, 2020 · 4 comments
Labels
Breaking Change NeededFor:Security Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@azasypkin
Copy link
Member

azasypkin commented Oct 27, 2020

Change description

Which release will ship the breaking change?

8.0 (Edit Joe 9/1/21: this is deprecated but we are not sure when we will get rid of it)

Describe the change. How will it manifest to users?

The /api/security/v1/saml route is no longer available, /api/security/saml/callback route must be used instead. This change should be reflected in Elasticsearch and Identity Provider SAML settings.

This change is external to Kibana and Kibana cannot know for sure if user needs to do anything. Kibana can only check if SAML is enabled in Kibana, but Elasticsearch can figure that out if it checks xpack.security.authc.realms.saml.{realm name}.sp.acs setting. Also some users may still use old route in server.xsrf.whitelist, we no longer need this setting, but if we notice that they still use it with the old route there will be a high chance they need to change their Elasticsearch and IdP configuration as well.

If users don't switch their configuration to /api/security/saml/callback they won't be able to log in with SAML (usually after login at the IdP users see just 404 generic error message).

How many users will be affected?

Everyone who uses SAML and still relies on the old route. I've seen a lot of such deployments in Cloud.

What can users do to address the change manually?

I'd suggest going through SAML Guide once again and pick up all the new changes we introduced for the past number of releases, including this one.

How could we make migration easier with the Upgrade Assistant?

If we can base our check on the current ES configuration (xpack.security.authc.realms.saml.{realm name}.sp.acs ) then we can pretty accurately say what needs to be changed on the ES side, and we should also ask users to double check if their IdP is configured to use the new route as well pointing them to the SAML Guide mentioned above.

Test Data

You can use Oktanaut to generate various SAML configurations for various versions and deployments (e.g. local or ESS). If you pick 7.8+ the config will use the new route, earlier versions will still rely on the old route.

Cross links

  • Upgrade Assistant issue where we already discussed this.
  • PR that implemented this change. (Edit Joe 9/1/21: this was reverted)

/cc @elastic/kibana-security

@azasypkin azasypkin added Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more Feature:Upgrade Assistant Breaking Change labels Oct 27, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui (Team:Elasticsearch UI)

@legrego legrego added the Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! label Nov 3, 2020
@alisonelizabeth
Copy link
Contributor

Hi @azasypkin! Can you clarify your comments under How could we make migration easier with the Upgrade Assistant? If I’m understanding correctly, it sounds like the best the Upgrade Assistant in Kibana could do is check if SAML is enabled and also if the server.xsrf.whitelist setting exists with the old route, and if so, warn the user that their Elasticsearch and IdP configuration may be change and point to the SAML docs. Does that sound right?

@azasypkin
Copy link
Member Author

If I’m understanding correctly, it sounds like the best the Upgrade Assistant in Kibana could do is check if SAML is enabled and also if the server.xsrf.whitelist setting exists with the old route, and if so, warn the user that their Elasticsearch and IdP configuration may be change and point to the SAML docs. Does that sound right?

Hey @alisonelizabeth! Yep, with one caveat though: having old route in the server.xsrf.whitelist would make our guess much stronger, but this setting isn't required anymore and we ignore it. That means that users may still need to update their ES and IdP configuration even if server.xsrf.whitelist isn't used.

@alisonelizabeth
Copy link
Contributor

I'm going to remove the Elasticsearch UI team label. Moving forward, this deprecation should be registered by the plugin owner via the core deprecations service (#94845). All registered deprecations will be displayed in the Upgrade Assistant (to be implemented via #97159). Feel free to reach out to myself or the core team with any questions!

@alisonelizabeth alisonelizabeth removed the Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more label Apr 19, 2021
@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Aug 5, 2021
@exalate-issue-sync exalate-issue-sync bot added loe:medium Medium Level of Effort and removed loe:small Small Level of Effort labels Sep 29, 2021
@exalate-issue-sync exalate-issue-sync bot added loe:small Small Level of Effort and removed loe:medium Medium Level of Effort labels Feb 14, 2022
@legrego legrego removed EnableJiraSync loe:small Small Level of Effort impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. labels Aug 18, 2022
gwbrown pushed a commit to elastic/elasticsearch that referenced this issue Oct 12, 2023
/api/security/saml/callback is the correct URL, while /api/security/v1/saml is the deprecated URL.

See also: elastic/kibana#81733

Fixes: #99986

---------

Co-authored-by: Craig Rodrigues <[email protected]>
Signed-off-by: Athena Brown <[email protected]>
gwbrown pushed a commit to elastic/elasticsearch that referenced this issue Oct 12, 2023
/api/security/saml/callback is the correct URL,
while /api/security/v1/saml is the deprecated URL.

See also: elastic/kibana#81733

Fixes: #99985

---------

Co-authored-by: Craig Rodrigues <[email protected]>
Signed-off-by: Athena Brown <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change NeededFor:Security Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

5 participants