ECE - SAML integration error

(Andrea Fuggetta) #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.

(Alex Piggott) #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?

(Andrea Fuggetta) #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"
                    }
                  }
                }
              }
            }
      }
    }
(Alex Piggott) #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?

(Alex Piggott) #5

And what does your ping federation config look like?

(Andrea Fuggetta) #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)

(Alex Piggott) #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?

(Andrea Fuggetta) #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"}

(Alex Piggott) #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...

(Andrea Fuggetta) #10

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

(Alex Piggott) #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

(Andrea Fuggetta) #12

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