# Elastic Cloud SAML XSRF Header

**URL:** <https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582>\
**Category:** Kibana\
**Tags:** elastic-stack-security\
**Created:** [December 12, 2018, 4:35pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582 "2018-12-12T16:35:50Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![ajrvester](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@ajrvester](https://discuss.elastic.co/u/ajrvester)\
**Post date:** [December 12, 2018, 4:35pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/1 "2018-12-12T16:35:50Z")

</div>

We've updating our deployments to Elastic Cloud 6.5.2 so we can take advantage of the new SAML integration.

Two of our deployments are now using the SAML integration to connect to our AD FS IdP without issue. However, our third deployment is not working, even with an equivalent configuration in Elasticsearch and Kibana.  
The configuration on the IdP side is also equivalent between the three deployments. When we attempt an IdP initiated sign on we receive an error message from Kibana after the SAML request:

`{"statusCode":400,"error":"Bad Request","message":"Request must contain a kbn-xsrf header."}`

My understanding is this relates to the `kibana.yml` setting for white-listing paths from XSRF header validation. Beyond that we are not sure what the issue is.  
I should note that we first attempted running the 'bad deployment' behind a proxy so we could use our own domain name and certificate. We had originally thought  
this was the source of the problem, but since reverting the configuration to the default Kibana URL without the proxy we still receive the error. Here are two of the  
configuration sets, they appear to be equivalent:

Working Deployment:

```auto
xpack.security.authc.realms.cloud-saml: 
  type: saml
  order: 2
  attributes.principal: "nameid:persistent" 
  attributes.groups: "groups" 
  idp.metadata.path: "https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml" 
  idp.entity_id: "http://adfs.example.com/adfs/services/trust"
  sp.entity_id: "https://good-deployment.us-east-1.aws.found.io:9243/" 
  sp.acs: "https://good-deployment.us-east-1.aws.found.io:9243/api/security/v1/saml"
  sp.logout: "https://good-deployment.us-east-1.aws.found.io:9243/logout"

```

```auto
xpack.security.public:
  protocol: "https"
  hostname: "good-deployment.us-east-1.aws.found.io"
  port: 9243

```

Non-working Deployment:

```auto
xpack.security.authc.realms.cloud-saml: 
  type: saml
  order: 2
  attributes.principal: "nameid:persistent" 
  attributes.groups: "groups" 
  idp.metadata.path: "https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml" 
  idp.entity_id: "http://adfs.example.com/adfs/services/trust"
  sp.entity_id: "https://bad-deployment.us-east-1.aws.found.io:9243/" 
  sp.acs: "https://bad-deployment.us-east-1.aws.found.io:9243/api/security/v1/saml"
  sp.logout: "https://bad-deployment.us-east-1.aws.found.io:9243/logout"

```

```auto
xpack.security.public:
  protocol: "https"
  hostname: "bad-deployment.us-east-1.aws.found.io"
  port: 9243

```

I'm looking for suggestions on next steps for figuring out what the issue might be.

---

<div class="post-metadata">

**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\
**Post date:** [December 12, 2018, 8:22pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/2 "2018-12-12T20:22:07Z")

</div>

Hey,

Have you gone through the [documentation](https://www.elastic.co/guide/en/elastic-stack-overview/current/saml-guide.html) ? We have a section for [kibana config](https://www.elastic.co/guide/en/elastic-stack-overview/current/saml-kibana.html) (that also contains a link to Kibana's relevant documentation page) that describes that you need to set

```auto
server.xsrf.whitelist: [/api/security/v1/saml]

```

in kibana.yml, among other. Can you verify this is set in all Kibana deployements ( especially the not working one ) ? Also can you please share a larger part of the kibana logs ?

---

<div class="post-metadata">

**Author:** ![ajrvester](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@ajrvester](https://discuss.elastic.co/u/ajrvester)\
**Post date:** [December 12, 2018, 8:34pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/3 "2018-12-12T20:34:25Z")

</div>

Woops, I did not include the entire Kibana configuration. Yes we have that setting there in all three deployments:

```auto
xpack.security.authProviders: ["saml", "basic"]
server.xsrf.whitelist: ["/api/security/v1/saml"]
xpack.security.public:
  protocol: "https"
  hostname: "good-deployment.us-east-1.aws.found.io"
  port: 9243

```

```auto
xpack.security.authProviders: ["saml", "basic"]
server.xsrf.whitelist: ["/api/security/v1/saml"]
xpack.security.public:
  protocol: "https"
  hostname: "bad-deployment.us-east-1.aws.found.io"
  port: 9243

```

Sorry about that.

We have looked at this [documentation](https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html) for the latest release of Elastic Cloud. We looked at some other settings from the non-cloud SAML realms, they don't seem to be supported in the cloud realm so we've stuck to that EC-specific documentation since then.

What specifically am I looking for in the Kibana logs? Are those stored with the Elasticsearch logs in the Elastic Cloud console?

---

<div class="post-metadata">

**Author:** ![ajrvester](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@ajrvester](https://discuss.elastic.co/u/ajrvester)\
**Post date:** [January 2, 2019, 7:11pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/4 "2019-01-02T19:11:24Z")

</div>

Tried restarting Kibana and the Elasticsearch cluster to make sure that the configuration were applied correctly, but we are still running into the same issue.

Is there anything else you could suggest we try?

---

<div class="post-metadata">

**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\
**Post date:** [January 3, 2019, 7:54am UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/5 "2019-01-03T07:54:28Z")

</div>

This all points to a misconfiguration in the non-working instance. Apologies if this sounds too obvious but have you checked your kibana saml config for typos, trailing spaces, extra characters etc ?

@Brandon_Kobel, do you happen to have an idea of would could be the issue here from Kibana's perspective ?

---

<div class="post-metadata">

**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\
**Post date:** [January 3, 2019, 2:33pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/6 "2019-01-03T14:33:59Z")

</div>

The `{"statusCode":400,"error":"Bad Request","message":"Request must contain a kbn-xsrf header."}` response alludes to the `server.xsrf.whitelist:` setting in the kibana config being incorrect, which you've already recommended they double check.

I was able to not set the `xpack.security.public` settings in the Kibana config as well when running in Cloud, perhaps that is worth a try?

---

<div class="post-metadata">

**Author:** ![ajrvester](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@ajrvester](https://discuss.elastic.co/u/ajrvester)\
**Post date:** [January 3, 2019, 3:32pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/7 "2019-01-03T15:32:47Z")

</div>

Thanks for the reply.

Yeah I understand its hard to suggest something else for me to check, it really does seem like a misconfiguration.

I ran both configurations through a diff-ing tool, doesn't appear to be anything unusual like trailing whitespace, improper indentation or extra slashes. From what I can tell they still appear to be equivalent configurations between deployments.

I tried removing the `xpack.security.public` segment of the Kibana configuration. The already working configuration continued to function, the non-working configuration is still running into the same issue. This makes configuration simpler though, which is nice!

I also captured the SAML response headed to each deployment and diff-ed those as well, they only appear to differ in the places you'd expect (audience, destination, etc). Both of those fields have the same format in both SAML responses.

---

<div class="post-metadata">

**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\
**Post date:** [January 3, 2019, 7:04pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/8 "2019-01-03T19:04:35Z")

</div>

At this point, it's probably worth-while to open up a Cloud Support ticket [here](https://www.elastic.co/cloud/elasticsearch-service/support) to have them look at the logs for your specific cluster to figure out what could be going awry.

---

<div class="post-metadata">

**Author:** ![ajrvester](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@ajrvester](https://discuss.elastic.co/u/ajrvester)\
**Post date:** [January 3, 2019, 8:12pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/9 "2019-01-03T20:12:44Z")

</div>

Will do, thanks for the help!

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 31, 2019, 8:23pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-xsrf-header/160582/10 "2019-01-31T20:23:59Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.