V: 1.13 - SAML and Basic Auth will not co-exist


I’ve set up my config.yml to the following, as described in the docs to handle this scenario:

    description: "Authenticate via HTTP Basic against internal users database"
    http_enabled: true
    transport_enabled: true
    order: 0
      type: basic
      challenge: false
      type: internal
    http_enabled: true
    transport_enabled: false
    order: 1
      type: saml
      challenge: true
          entity_id: {{idp_entity_id}}
          metadata_file: saml_metadata.xml
          entity_id: opendistro-saml
        kibana_url: {{kibana_url}}
        roles_key: {{role_key}}
        exchange_key: '{{some_key}}'
      type: noop

This config pushes with no errors while running securityadmin.sh

However, while this allows SAML authentication for Kibana (after updating kibana.yml), it seems to break the Basic authentication. When I go to :9200 via a web browser, I get an immediate 401 error with no prompt to authenticate, and API requests will also throw a 401 after supplying the correct credentials.

I’m at my wit’s end, as I’ve looked at the sample config in the docs and compared it with mine and I’m not seeing any difference. It’s likely that it’s something small that I’m not seeing or forgot to do…

Any help would be greatly appreciated!

IMO accessing the 9200 with a browser is normal behaviour. But you should be able to do curl -k -u $USERNAME:$PASSWORD https://yourhostname:9200/ and get a result. As long as your username and password exist in the internal database. IDK if it is possible to use SAML directly without Kibana.

1 Like

Ah okay, yeah I can confirm that I was able to place an API request using curl. When I was having issues with API I was using Powershell, and ES didn’t like the basic auth coming from the “-Credential” flag.

Anyways, thanks for letting me know that this is expected. Appreciate your time replying to this non-issue.

1 Like