Elastic Cloud SAML SSO in 'trial' environment

alongaks · February 14, 2023, 7:14pm

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 as a reference.

Below is the configuration I am using for Kibana:

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:

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, but unsure if one set of documentation is preferred over another in this scenario.

Any insight is appreciated.

Sean_Story · February 14, 2023, 8:31pm

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.

alongaks · February 14, 2023, 8:43pm

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:

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.

Sean_Story · February 14, 2023, 9:39pm

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:

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.

alongaks · February 16, 2023, 4:48pm

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:

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:

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:

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?

Sean_Story · February 16, 2023, 9:59pm

From the documentation
You should be using the KIBANA_ENDPOINT_URL:

xpack:
  security:
    authc:
      realms:
        saml: 
          saml-realm-name: 
            order: 2 
            attributes.principal: "nameid:persistent" 
            attributes.groups: "groups" 
            idp.metadata.path: "<check with your identity provider>" 
            idp.entity_id: "<check with your identity provider>" 
            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:

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:

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#/ 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#/, 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?

alongaks · February 17, 2023, 4:34pm

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:

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:

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!

Yang_Wang · February 20, 2023, 4:22am

The service provider settings (e.g. sp.acs) need to be configured with Kibana endpoint URLs as said in the documentation, e.g.:

...
    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.

Sean_Story · February 22, 2023, 7:45pm

You're so close!

I actually think it's a minor typo. You have:

  sp.acs: "https://deployment-name.es.us-east-1.aws.elastic-cloud.com:9243/api/security/saml1/callback"

You want:

  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.

alongaks · February 22, 2023, 8:42pm

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:

  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

Sean_Story · February 22, 2023, 8:59pm

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.

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.

alongaks · February 22, 2023, 9:11pm

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?

Sean_Story · February 22, 2023, 9:29pm

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.

Yang_Wang · February 22, 2023, 11:24pm

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.

alongaks · February 23, 2023, 1:07pm

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!

system · March 23, 2023, 1:08pm

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