Allow HTTP routes to programmatically opt out of XSRF protection

[azasypkin]

Currently we have routes that are solely used by the external services (e.g. SAML POST callback route that is called by Identity Provider). Usually such services can't be configured to provide kbn-xsrf HTTP header with their requests and trigger our server XSRF protection as the result.

To workaround that we introduced server.xsrf.whitelist configuration a while ago, but that was never convenient since you should always configure it if you wish to use SAML and with a value that's already known to Kibana (/api/security/saml/callback).

We're a looking for a better way to XSRF-whitelist certain endpoints and eliminate unnecessary admin/user involvement that'd simplify overall setup process. I can think of two options right now:

• Provide additional route option to mark route as XSRF-whitelisted (similar to authRequired: boolean we already have).

• Expose programmatic core.http.xsrf-like API that would allow run-time editing of XSRF whitelist.

The first option sounds like a better one overall: simple to understand and easy to audit but I'd like to hear your thoughts on that @elastic/kibana-platform @elastic/kibana-security ?

[kobelb]

The first option sounds like a better one overall: simple to understand and easy to audit

I also prefer this option because it's immediately obvious from the route definition that we're disabling the XSRF protection and on the surface it seems like less effort.

[jportner]

+1 for the first option.

[pgayvallet]

Related to the changes done in #53684

+1 for first option too.

[mshustov]

+1 for the first option provided that we delete server.xsrf.whitelist.

[pgayvallet]

@restrry isn't server.xsrf.whitelist for a different usage though? I thought it was present to allow users to explicitely allow cross domains call to some endpoints of their choosing, if they had external API/servers calling Kibana backend for example?

[mshustov]

@pgayvallet as I can see our docs recommend to set xsrf header for this case:

It is not recommended to disable protections for arbitrary API endpoints. Instead, supply the kbn-xsrf header. There are some scenarios where whitelisting is required, however, such as SAML and OpenID Connect Single Sign-On setups.

https://github.com/elastic/kibana/blob/master/docs/setup/settings.asciidoc

it looks like this parameter has been introduced for 3rd party IP endpoints. @azasypkin can provide more details.

[azasypkin]

it looks like this parameter has been introduced for 3rd party IP endpoints. @azasypkin can provide more details.

Yeah, not much to add here. As far as I'm aware it's only used for SAML/OIDC IdPs (at least that was the initial intention) that can't be configured to send additional headers (usually these are 3rd-parties that you don't have much control over). Any other clients are supposed to provide kbn-xsrf header.

[pgayvallet]

Ok, thanks for the info

[azasypkin]

Thanks everyone for the feedback!

It seems we have a consensus now. @elastic/kibana-platform this functionality would really help us with #39313 that's requested for 7.7, is there any chance you can include this new feature into your 7.7 roadmap?

[mshustov]

@azasypkin moved to 7.7 backlog