Elasticsearch cloud SAML settings errors

Elastic Stack Elasticsearch
1

I am running ES version v7.1.0 on the cloud . I am not able to enter the SAML settings for OKTA integration in the "User settings overrides" box. It is throwing errors like 'xpack.security.authc.realms.cloud-saml.type': is not allowed

According to this link, settings are limited. Where do I put in the SAML settings ?

https://www.elastic.co/guide/en/cloud/current/ec-add-user-settings.html

2

Realms settings were changed slightly in Elasticsearch 7, which makes it difficult for the cloud documentation (because cloud supports multiple versions of Elasticsearch).

We're working on fixing the docs for this.

In 6.x, your cloud SAML realm should look like this:

xpack:
  security:
    authc:
      realms:
        cloud-saml: 
          type: saml
          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/v1/saml"
          sp.logout: "KIBANA_ENDPOINT_URL/logout"

In 7.x, that same configuration should look like:

xpack:
  security:
    authc:
      realms:
        saml: 
          cloud-saml:
            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/v1/saml"
            sp.logout: "KIBANA_ENDPOINT_URL/logout"

What used to be a "type" in the realm (cloud-saml.type: saml) is now part of the configuration key.

3

This worked . thank you . But kibana does not appear to log me out completely . it appears like an authentication loop. How do i get back to my OKTA page ?

image
image.png1400×428 22 KB

4

Can you explain in a little more detail:

  • What is the behavior you experience after logout
  • What would you like to happen instead? What is the behavior you'd want to see.

Can you also share your cloud-saml realm configuration?

5

As you can see in the screenshot posted earlier, user lands on the kibana login page after logging out . Click on 'login' will take the user back to Kibana. I would like the user to land on the OKTA login screen after logging out of Kibana.

here are the Elasticsearch and Kibana user settings

Elasticsearch user settings>>

xpack:
  security:
    authc:
      realms:
        saml: 
          cloud-saml:
            order: 2
            attributes.principal: "nameid:persistent"
            attributes.groups: "groups"
            idp.metadata.path: "https://xxxxxxx.okta.com/app/exkl4glcoc065460h7/sso/saml/metadata"
            idp.entity_id: "http://www.okta.com/ffffffffffffffff"
            sp.entity_id: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/"
            sp.acs: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/api/security/v1/saml"
            sp.logout: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/logout"

kibana user settings>>

xpack.security.authProviders: [saml, basic]
server.xsrf.whitelist: [/api/security/v1/saml]
xpack.security.public:
  protocol: https
  hostname: dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io
  port: 9243

in addition , i ran something like on the API console. "elasticadmins" is a group created in OKTA . Users added to the group

POST /_xpack/security/role_mapping/CLOUD_SAML_ELASTICADMIN_TO_SUPERUSER 
{
   "enabled": true,
    "roles": [ "superuser" ], 
    "rules": { "all" : [ 
        { "field": { "realm.name": "cloud-saml" } }, 
        { "field": { "groups": "elasticadmins" } }
    ]},
    "metadata": { "version": 1 }
}
6

@ajayraghuraj just a quick note that formating your code/logs/config using the </> button, or markdown style back ticks really helps to make things easy to read which helps us help you :slight_smile:

7

@warkolm edited and formatted :slight_smile:

1 Like
8

The behavior you are seeing means that either Okta is not configured to support Single Logout and thus Elasticsearch assumes there is no point to redirect you to the SAML IdP. You can verify that by looking at your Okta configuration or by looking at the metadata in https://xxxxxxx.okta.com/app/exkl4glcoc065460h7/sso/saml/metadata . I'd expect there is no <SingleLogoutService> in there ( this is the URL in Okta where the Elastic Stack would redirect you upon Logout ) .

You could contact Okta support to assist you in enabling Single Logout or look at their documentation.

Keep in mind that according to the SAML specification section 3.7 what usually happens in SAML Single Logout is that the session participant ( That is the Elastic Stack ) should redirect the user to the SAML IdP ( that is Okta ) with a SAML Logout Request and then the SAML IDP will attempt to terminate the session and redirect the user back to the Session Participant with a SAML Logout response. This would mean that you would still end up in Kibana after completing the logout - unless Okta has some setting to keep you to their Dashboard, instead of redirecting you back to Kibana with the SAML Response in the end.

9

Okay. Do I need to generate a certificate from the SP ( elasticsearch stack ) and upload into OKTA ? I believe the cert is required for decrypting the assertion ?

Step#9

https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Interact.html

10

No, that is not required (but it is possible).

SAML assertions are typically signed (using the IdP's certificate) but not encrypted.

If configured correctly, the idp.metadata.path provides Elasticsearch with a copy of the certificate it needs to verify the signature.

If you want to use encrypted assertions, that is possible and is documented here:

11

Thanks Tim. Our OKTA service provider have asked for Single Logout URL, SP Issuer (usually same as entity id) and Signature Certificate to enable single logout

12

Your previous question was asking about encryption, rather than signing. They are different.

The link I provided above describes how to configure the SAML realm to sign logout requests.

13

I managed to generate the signing certificates with Openssl instead of elasticsearch-certutil . OKTA has been enabled for SLO. But here is the problem we are seeing now on the browser upon logout from Kibana

"{"statusCode":404,"error":"Not Found","message":"Not Found"}"

elasticsearch user settings

xpack:
  security:
    authc:
      realms:
        saml: 
          cloud-saml:
            order: 2
            attributes.principal: "nameid:persistent"
            attributes.groups: "groups"
            idp.metadata.path: "https://xxxxxxx.okta.com/app/exkl4glcoc065460h7/sso/saml/metadata"
            idp.entity_id: "http://www.okta.com/ffffffffffffffff"
            sp.entity_id: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/"
            sp.acs: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/api/security/v1/saml"
            sp.logout: "https://dfwgfewrttrgrgg4gr4grgregrewgre.cloud.es.io:9243/logout"
	        signing.certificate: saml/saml-sign.crt
            signing.key: saml/saml-sign.key
14

Please, please , share more information. This is very little for anyone to try and assist in a meaningful way. 404 is just an HTTP error code, it doesn't mean much on its own. The more time you put in making your questions clear with all the details required, the fewer questions we'd have to ask back, and the more probable it will become that someone will take the time to try and help you resolve the problem.

What happens when you click on the logout, where does your browser get redirected to ? What is the URL that gives you this 404 ? Even better, capture a HAR for your browser when you click on logout and share it with us by uploading it somewhere.

15

I ran a SAML tracer . noticed two GET and one POST request. My understanding is that the first GET request relates to the 'logout' from Kibana. URL in the Second GET is the 'HTTP REDIRECT'. But i dont understand why i get a POST response for the second 'GET' URL. The POST response is what is throwing the "404" error . let me know if this helps

InkedCapture2
InkedCapture2.gif1920×824 143 KB

16

still not able to sort this . anyone have ideas ?

17

I noticed a conversation on github similar to the issue i am facing . So does Kibana not handle the SAML logout response issued by the session authority ( OKTA ) ?

18

The POST appears to be sent incorrectly from Okta.
I think you may need to follow up with them to find out why they are sending it.

Kibana's Logout endpoint only accepts GET because it is designed to support the HTTP-Redirect binding (per the SAML interoperability profile) and does not support the HTTP-POST binding.

I cannot see any way to change that in the Okta configuration screens, so I think it may require a conversation with Okta.

At the moment we have 2 issues in the stack related to logout.

  1. In some cases we can end up in a logout loop, where immediately after logging out you get sent back to the IdP Login page which might automatically log you in again.
  2. The issue referenced above, which is a fairly technical issue which does interact with the problem you're facing, and can make the logout loop worse, but isn't actually causing the issue here.
19

Thanks Tim. I am working with OKTA support on this one. Will let you know if there is any progress

In some cases we can end up in a logout loop, where immediately after logging out you get sent back to the IdP Login page which *might* automatically log you in again.

what I noticed with the OKTA SSO integration is that the user session is terminated from the browser that initiated the log out . But I will still be able to login without re-authenticating if I have an active browser session on OKTA. Ideally when the user logs out of Kibana, all sessions for that user must end

20

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