# Elastic Cloud SAML SSO in 'trial' environment **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [February 14, 2023, 7:14pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509 "2023-02-14T19:14:56Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 14, 2023, 7:14pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/1 "2023-02-14T19:14:56Z")
Hello, I'm looking for some insight with configuring SAML SSO in a trial Elastic Cloud environment. The deployment is on v8.6.1. Using Elasticsearch, Kibana, Enterprise Search. The idP provider is SAML 2.0. I have been using the [SAML documentation here](https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html) as a reference. Below is the configuration I am using for Kibana: ```auto xpack: security: authc: realms: saml: order: 2 attributes.principal: "nameid:persistent" idp.metadata.path: "idP_metadata_php_page" idp.entity_id: "ENT-ID" sp.entity_id: "AWS_Kibana_instance:9243" sp.acs: "AWS_Kibana_instance:9243/api/security/saml/callback" sp.logout: "AWS_Kibana_instance:9243/logout" ``` When trying to apply this to the deployment, it comes back with the following and I'm not sure if this is a syntax/config issue with the above or a limitation of being on a 'trial' deployment: ```auto Your changes cannot be applied Kibana - 'xpack.security.authc.realms.saml.sp.logout': is not allowed Kibana - 'xpack.security.authc.realms.saml.sp.acs': is not allowed Kibana - 'xpack.security.authc.realms.saml.sp.entity_id': is not allowed Kibana - 'xpack.security.authc.realms.saml.idp.entity_id': is not allowed Kibana - 'xpack.security.authc.realms.saml.idp.metadata.path': is not allowed Kibana - 'xpack.security.authc.realms.saml.attributes.principal': is not allowed Kibana - 'xpack.security.authc.realms.saml.order': is not allowed ``` I have also been going down [some other documentation referring SAML 2.0](https://www.elastic.co/guide/en/elasticsearch/reference/current/saml-guide-stack.html), but unsure if one set of documentation is preferred over another in this scenario. Any insight is appreciated. ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 14, 2023, 8:31pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/2 "2023-02-14T20:31:49Z")
> Below is the configuration I am using for Kibana: I believe you've put Elasticsearch configurations in your Kibana configuration section. - `xpack.security.authc.realms...` is an Elasticsearch block of configuration options. - `xpack.security.authc.providers...` is the corresponding Kibana block of configuration options. Be sure that you have the right configurations in the right "user settings" section when you go to the `Edit` tab of your deployment. ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 14, 2023, 8:43pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/3 "2023-02-14T20:43:44Z")
Ah! Thanks, Sean! Well, I stuck the above config into Elasticsearch instead, but am getting the same output, but includes lines like so as well: ```auto Elasticsearch - 'xpack.security.authc.realms.saml.attributes': is missing required field: order ``` I'm going to continue down the docs and see if there is additional stuff I'm not including. ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 14, 2023, 9:39pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/4 "2023-02-14T21:39:56Z")
ah ok, this issue is that between `saml` and `attributes` you're supposed to have the name of the realm that you are defining. It can be anything, as long as you're consistent about it in your kibana settings too. Like: ```auto xpack.security.authc.realms.saml.my-realm-name: order: 3 idp.metadata.path: "https://YOUR_SAML_IDP/metadata" idp.entity_id: "urn:example:idp" sp.entity_id: "http://localhost:5601" sp.acs: "http://localhost:5601/api/security/saml/callback" sp.logout: "http://localhost:5601/logout" attributes: principal: "email" ``` uses `my-realm-name`. ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 16, 2023, 4:48pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/5 "2023-02-16T16:48:13Z")
Ultimately I'd like to configure SSO into the Elastic Cloud app dashboard - the Kibana 'Welcome home' screen one gets when using a standard local login into the deployment. This portal provides the other stack apps like Enterprise Search, Observability, Security, Analytics, etc. ... putting this URL/app behind an SSO login: `https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/` I am able to get the following configuration applied to Kibana User Settings from 'Edit deployment' in the console, and it provides a login button on the sp.entity\_id page: `https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243` Kibana User Settings: ```auto xpack.security.authc.providers: saml.saml1: order: 0 realm: saml1 maxRedirectURLSize: 4kb description: "SSO Login" ``` 'realm' being an Elasticsearch configuration, when I put in realm information into the console for Elasticsearch 'user settings', it is accepted when applying... Elasticsearch User Settings: ```auto xpack.security.authc.realms.saml.saml1: order: 2 attributes.principal: "nameid" idp.metadata.path: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" idp.entity_id: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" sp.entity_id: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com" sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com/api/security/saml1/callback" sp.logout: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com/logout" ``` ... when I browse to the Kibana sp.entity\_id: ```auto https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243 ``` I get a page with the 'SSO Login' button. Clicking that sends me to the company idP login. That then rolls to a MFA, the acceptance of the MFA then rolls to an error page because it is sending me to the Elasticsearch app ( based on the realm created ) but not Kibana. Also likely due to the realm metadata is for Elasticsearch, pulled from the 'DevTools' in the deployment dashboard given to the idP. The error page URL is `https://deployment-name.es.us-east-1.aws.elastic-cloud.com/api/security/saml1/callback` error is: `{"error":"no handler found for uri [/api/security/saml1/callback] and method [POST]"}` I have tried to put the 'kb' URL in the 'sp.x' spots of the Elasticsearch configuration, it does not come back with notices that you can't, but when applying the config to the deployment, it runs for ~8min then the change fails and reverts back as a 'fail'. Likely due to it not liking that I am referencing a 'kb' provider URL in an Elasticsearch config. Good though that it proactively rolls back to a prior stable config. Can the Kibana 'Welcome home' portal ( `https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/` ) be put behind an SSO login, or is SSO functionality only for individual stack apps directly - Elasticsearch, a separate Kibana dashboard, Enterprise Search? ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 16, 2023, 9:59pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/6 "2023-02-16T21:59:18Z")
From [the documentation](https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html) You should be using the `KIBANA_ENDPOINT_URL`: ```auto xpack: security: authc: realms: saml: saml-realm-name: order: 2 attributes.principal: "nameid:persistent" attributes.groups: "groups" idp.metadata.path: "" idp.entity_id: "" sp.entity_id: "KIBANA_ENDPOINT_URL/" sp.acs: "KIBANA_ENDPOINT_URL/api/security/saml/callback" sp.logout: "KIBANA_ENDPOINT_URL/logout" ``` But looking at your pasted snippet, you've configured the _Elasticsearch URL_: ```auto xpack.security.authc.realms.saml.saml1: order: 2 attributes.principal: "nameid" idp.metadata.path: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" idp.entity_id: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" sp.entity_id: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com" sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com/api/security/saml1/callback" sp.logout: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com/logout" ``` These should be, instead: ```auto xpack.security.authc.realms.saml.saml1: order: 2 attributes.principal: "nameid" idp.metadata.path: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" idp.entity_id: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" sp.entity_id: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243" sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml1/callback" sp.logout: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/logout" ``` with the `:9243` port after the host. > Can the Kibana 'Welcome home' portal ( `https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/` ) be put behind an SSO login, or is SSO functionality only for individual stack apps directly - Elasticsearch, a separate Kibana dashboard, Enterprise Search? That's what we're working to do for you. However, you cannot remove "Login With Elastic Cloud" as one of the configured authentication realms. So you, as an admin, will likely browse to [https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/](https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/) having already logged in to Elastic Cloud, and therefore not be asked to login via SAML. You can logout, and then go to [https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/](https://deployment-name.kb.us-east-1.aws.elastic-cloud.com:9243/app/home#/), and that will force you to choose your authentication realm (at which point you can choose SAML). For your users who do not have this deployment in their Elastic Cloud, they will _have_ to choose another authentication realm. Does that make sense? ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 17, 2023, 4:34pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/7 "2023-02-17T16:34:59Z")
Hi, Sean Yep, makes sense and yes, no problem with having the 'Log in with Elastic Cloud' button still available. I am confusing the ecosystem of the stack so that is probably getting in my way, admittedly. So, the cloud Elasticsearch instance is the central location to configure SSO for whatever app in the stack you want to use it with. If Kibana, reference the port number of the Kibana instance in the `sp.x` configs, using the parent `'.es.'` reference in the endpoint name. Using the mentioned config set as the means to do it: ```auto xpack.security.authc.realms.saml.saml1: order: 2 attributes.principal: "nameid" idp.metadata.path: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" idp.entity_id: "https://idP-provider-URL/simplesaml/saml2/idp/metadata.php" sp.entity_id: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243" sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml1/callback" sp.logout: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/logout" ``` I had the same Kibana user settings to add the log in button: ```auto xpack.security.authc.providers: saml.saml1: order: 0 realm: saml1 description: "SSO Login" ``` So if anyone wants to use the Kibana dashboard, they will use the `https://deployment-name. **kb**.us-east-1.aws.elastic-cloud.com:9243`. Testing this, it does hit the idP, the login there then rolls to the MFA, then it his an error on the URL `https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml1/callback` `error "no handler found for uri [/api/security/saml1/callback] and method [POST]"` I double-checked the Elasticsearch User Settings have the intended endpoint. Not sure if this is an idP thing or a Elastic config. If I try to browse to the `https://deployment-name. **es**.us-east-1.aws.elastic-cloud.com:9243` it goes to a pop-out login window and not the idP. Really appreciate the assistance thus far! ---
**Author:** ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)\ **Post date:** [February 20, 2023, 4:22am UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/8 "2023-02-20T04:22:30Z")
The service provider settings (e.g. `sp.acs`) need to be configured with Kibana endpoint URLs as said in the [documentation](https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html#ec_configure_your_8_0_or_above_cluster_to_use_saml), e.g.: ```auto ... sp.acs: "KIBANA_ENDPOINT_URL/api/security/saml/callback" ``` That's why you got the "no handler found" error. Authentication with SAML requires both Elasticsearch and Kibana to work together. I believe `https://deployment-name. **es**.us-east-1.aws.elastic-cloud.com:9243` is an URL to Elasticsearch. You need hit Kibana UI first to initiate SAML SSO flow. ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 22, 2023, 7:45pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/9 "2023-02-22T19:45:01Z")
You're so close! I actually think it's a minor typo. You have: ```auto sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml1/callback" ``` You want: ```auto sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml/callback" ``` (`saml` vs `saml1`) As @Yang_Wang says, that endpoint is something baked into kibana, so you don't use your realm name there. ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 22, 2023, 8:42pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/10 "2023-02-22T20:42:01Z")
Hehe! Thank you Sean and Yang very much for continuing to help! Ok so to confirm, I'm doing below, _ **without** _ the realm name in the `sp.acs` line, and pointing to the ES deployment, referencing the port for Kibana: ```auto sp.entity_id: "https://deployment-name. **es**.us-east-1.aws.elastic-cloud.com:9243" sp.acs: "https://deployment-name. **es**.us-east-1.aws.elastic-cloud.com:9243/api/security/saml/callback" sp.logout: "https://deployment-name. **es**.us-east-1.aws.elastic-cloud.com:9243/logout" ``` I'm _ **not** _ to use the full Kibana endpoint URL ( with kb in it ) you lift from the Elastic Cloud console: `https://deployment-name. **kb**.us-east-1.aws.elastic-cloud.com:9243` ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 22, 2023, 8:59pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/11 "2023-02-22T20:59:34Z")
> [@alongaks](#): > > I'm _ **not** _ to use the full Kibana endpoint URL ( with kb in it ) you lift from the Elastic Cloud console: `https://deployment-name. **kb**.us-east-1.aws.elastic-cloud.com:9243` Without access to your cloud deployment, it's hard for me to tell you exactly what this should look like and not risk missing some small nuance in the hostname. You should copy the Kibana endpoint from your cloud admin page for your deployment, and use it everywhere that the documentation says `KIBANA_ENDPOINT_URL`. ![Screenshot 2023-02-22 at 2.56.49 PM](https://us1.discourse-cdn.com/elastic/original/3X/c/a/ca31e559997565e38f2c444ed9219c2c610056f9.png) That URL and your IDP url are the _only_ hosts that you should need to copy/configure, and both are just used in several configuration lines with different paths appended to them. ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 22, 2023, 9:11pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/12 "2023-02-22T21:11:39Z")
One more thing to make sure I am sending the proper metadata to the idP... ... If I use DevTools in the cloud deployment to run a `GET /_security/saml/metadata/saml1`, that is the proper XML out to hand to the idP? ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [February 22, 2023, 9:29pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/13 "2023-02-22T21:29:56Z")
I'm honestly not sure, but you _shouldn't_ have to worry about that. The SAML realm should handle all the interaction pieces for you. ---
**Author:** ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)\ **Post date:** [February 22, 2023, 11:24pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/14 "2023-02-22T23:24:24Z")
> [@alongaks](#): > > If I use DevTools in the cloud deployment to run a `GET /_security/saml/metadata/saml1`, that is the proper XML out to hand to the idP? If your idP can take Service Provider metadata, yes you can hand it to the idP. Otherwise you can configure it manually. The SP metadata is a convenience, not absolutely necessary. ---
**Author:** ![alongaks](https://avatars.discourse-cdn.com/v4/letter/a/df705f/32.png) [@alongaks](https://discuss.elastic.co/u/alongaks)\ **Post date:** [February 23, 2023, 1:07pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/15 "2023-02-23T13:07:40Z")
Again, appreciate the help. SSO login is now working. The next bit I need to work out appears to be assigning permissions to authenticated users. Thanks for all the help! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 23, 2023, 1:08pm UTC](https://discuss.elastic.co/t/elastic-cloud-saml-sso-in-trial-environment/325509/16 "2023-03-23T13:08:12Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.