ECE - SAML integration error

Elastic Orchestration Elastic Cloud Enterprise (ECE)
1

Hello,

I am trying to setup a SAML integration between ECE and PingFedaration.
I have setup the new SAML provider and I get the following error:

Authentication cluster failed to process the request Message: Authentication cluster failed the request. Status: [500]; Data: [{\"error\":{\"root_cause\":[{\"type\":\"security_exception\",\"reason\":\"Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=null, assertionConsumerServiceURL=**http**://xxxxxx.com:12443/api/v1/users/auth/saml/_callback}]\"}],\"type\":\"security_exception\",\"reason\":\"Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=null, assertionConsumerServiceURL=**http**://xxxxxx.com:12443/api/v1/users/auth/saml/_callback}]\"},\"status\":500}]

The odd thing is that the URL is showing as HTTP whereas I set the HTTPS one. I'm guessing that's the issue?

Below my settings:

Assertion consumer service URL: https://xxxxxx.com:12443/api/security/v1/saml (URL of admin console)
Logout URL: https://xxxxxx.com:12443/api/v1/users/auth/_logout (URL of admin console)

Other settings are private and will not share, most likely not relevant.

Thank you.

2

We're looking into this.

In the meantime, if you look at the advanced editor for the security deployment, you should see all those settings mirrored in the "Plan" section - can you sanitize and share them?

3

@Alex_Piggott find the settings below:

    "user_settings_override_json": {
          "xpack": {
            "watcher": {
              "enabled": false
            },
            "security": {
              "audit": {
                "enabled": true
              },
              "authc": {
                "realms": {
                  "found": {
                    "type": "file",
                    "order": 0
                  },
                  "native": {
                    "type": "native",
                    "order": 1
                  },
                  "saml": {
                    "force_authn": false,
                    "enabled": true,
                    "attributes": {
                      "principal": "principal",
                      "groups": "groups"
                    },
                    "idp": {
                      "entity_id": "https://xxxxxx.com",
                      "use_single_logout": true,
                      "metadata": {
                        "path": "https://xxxxxx/ECE_Prod_Metadata.xml"
                      }
                    },
                    "order": 2,
                    "type": "saml",
                    "sp": {
                      "entity_id": "xxxxxx",
                      "acs": "https://xxxxxx.com:12443/api/security/v1/saml",
                      "logout": "https://xxxxxx.com:12443/api/v1/users/auth/_logout"
                    }
                  }
                }
              }
            }
      }
    }
4

OK so the cluster is correctly configured, so the rogue HTTP is coming from elsewhere

What URL are you using to access the adminconsole? Is there a reverse proxy anywhere in the architecture?

5

And what does your ping federation config look like?

6

The admin console URL is: https://xxx.com:12443, I don't have any load balancer at the moment or reverse proxy.

I don't have direct access to the ping federation config but I checked with them and the config I sent is the following:

Endpoint URL/Assertion Consumer Service URL:
https://xxx.com:12443/api/security/v1/saml (Base is the Admin console URL)

Logout URL:
https://xxx.com:12443/api/v1/users/auth/_logout (Same base URL as above)

7

Looking at the code, it generates the ACS string that is failing by taking the URL of the saml/_init request and switching it to saml/_callback, leaving the rest of it unchanged. For some reason that URL seems to be http and not https

Can you look in the adminconsole logs for that saml/_init request (it will probably be in 2 places - the main adminconsole logs and also the audit logs, not sure which of the two will be most useful) and post what the logs say?

8

I see different entries in the logs:

[2019-05-14 14:19:44,084][INFO ][AuditRecordLoggerNoSensitive] {"request_id":"6a7a908fa3cf7bfc08009848390d0c75","method":"GET","path":"http://xxx.com:12443/api/v1/users/auth/saml/_init?state=%7B%22redirectTo%22:%22/%22%7D","headers":[{"name":"remote-address","value":"-"},{"name":"upgrade-insecure-requests","value":"1"},{"name":"connection","value":"keep-alive"},{"name":"dnt","value":"1"},{"name":"referer","value":"https://xxx.com:12443/login?redirectTo=%2F"},{"name":"accept-encoding","value":"gzip, deflate, br"},{"name":"accept-language","value":"en-US, en;q=0.5"},{"name":"accept","value":"text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8"},{"name":"user-agent","value":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0"},{"name":"host","value":"xxx.com:12443"},{"name":"x-forwarded-for","value":"-"}]} {}

This one shows the error:

[2019-05-14 14:19:44,128][ERROR][no.found.adminconsole.http.requests] 502 Bad Gateway - unknown - 127.0.0.1 - 127.0.0.1 - GET //xxx.com:12443/api/v1/users/auth/saml/_init HTTP/1.1 in:0 out:748 (45 ms) {"proxy_ip":"127.0.0.1","request_url":"//xxx.com:12443/api/v1/users/auth/saml/_init","status_code":"502","response_length":"748","response_time":"45","request_method":"GET","commit_hash":"ba6ca6d92527cbb64e4daf136f083bcc70e6e4b2","request_host":"xxx.com","request_id":"6a7a908fa3cf7bfc08009848390d0c75","request_length":"0","user":"unknown","client_ip":"127.0.0.1"}

9

Oh yeah they are both showing as HTTP :frowning:, looks like it's a problem on our side. Going to go dig some more...

10

Thanks for looking into this.
This step is important in our enterprise to show the value of the tool.

11

We're not finished looking into this, but it looks like the SAML support in beta only covers HTTP (obviously this is an oversight)

We'll be releasing a patch very soon to cover HTTPS support.

Apologies for the inconvenience, and thanks for the very helpful bug report

Alex

12

Thanks @Alex_Piggott, I'll keep an eye here for the patch release.

13

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