How to use /_dashboards/auth/login endpoint while SAML is enabled

OpenDistro
,
1

Hi OS/D community.

We have been using the /_dashboards/api/saved_objects/_import url to manage our saved objects via a bash script.
We have an internal user database configured with a ‘master’ user who has the ‘all_access’ role assigned.

We would authenticate with the /_dashboards/auth/login url, sending the user and password, then saving the cookies to authenticate the saved objects POST.

We’ve recently enabled SAML and have noticed that the /_dashboards/auth/login url now returns a 404.

How can we use this internal user authentication method as well as using SAML?
Have posted our securityconfig response with identifying details removed :slight_smile:

We’re using the AWS OpenSearch Service if that is relevant (most security config managed by aws)

{
    "config": {
        "dynamic": {
            "filtered_alias_mode": "warn",
            "disable_rest_auth": false,
            "disable_intertransport_auth": false,
            "respect_request_indices_options": false,
            "kibana": {
                "multitenancy_enabled": true,
                "server_username": "AmazonESKibanaServerUser",
                "index": ".kibana"
            },
            "http": {
                "anonymous_auth_enabled": false,
                "xff": {
                    "enabled": false,
                    "internalProxies": "ip-address-list",
                    "remoteIpHeader": "X-Forwarded-For"
                }
            },
            "authc": {
                "basic_internal_auth_domain": {
                    "http_enabled": true,
                    "transport_enabled": true,
                    "order": 4,
                    "http_authenticator": {
                        "challenge": false,
                        "type": "basic",
                        "config": {}
                    },
                    "authentication_backend": {
                        "type": "intern",
                        "config": {}
                    },
                    "description": "Authenticate via HTTP Basic against internal users database"
                },
                "saml_auth_domain": {
                    "http_enabled": true,
                    "transport_enabled": false,
                    "order": 5,
                    "http_authenticator": {
                        "challenge": true,
                        "type": "saml",
                        "config": {
                            "redacted": "true"
                        }
                    },
                    "authentication_backend": {
                        "type": "noop",
                        "config": {}
                    }
                }
            },
            "authz": {},
            "auth_failure_listeners": {},
            "do_not_fail_on_forbidden": false,
            "multi_rolespan_enabled": true,
            "hosts_resolver_mode": "ip-only",
            "do_not_fail_on_forbidden_empty": false
        }
    }
}
2

Hi @kevin-fun-with-osd.
I’m not sure if you ever got an answer, but our organization ran into the same exact problem. We ended up reaching out to AWS support to ask for their recommendation. They responded with a work around that I tested and worked for us. I figured I would post here in case anybody else ran into this issue.

==================
WorkAround

If you have enabled FGAC on the domain and the master user type is internal user database, you can perform signed HTTP requests[4] on the dashboards API to create index-pattern and below is an example code for the same:

import boto3
import requests
from requests_aws4auth import AWS4Auth

host = '' # include https:// and trailing /
region = '' # e.g. us-west-1
service = 'es'
credentials = boto3.Session().get_credentials()
awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token)

path = '_plugin/kibana/api/saved_objects/index-pattern' # kibana API
url = host + path

payload = {"attributes":{"title":"custom-logs-*","fields":"[]"}}

headers = {"Content-Type": "application/json", "kbn-xsrf": "true", "security_tenant": "<tenant-name>" }

r = [requests.post](http://requests.post/)(url, auth=awsauth, json=payload, headers=headers)

print(r.status_code)
print(r.text)

The above sample code will use IAM user/role credentials i.e. configured in your environment to access Opensearch service domain, and will perform kibana API call to create an index-pattern “custom-logs-*” in custom tenant “”.

NOTE: The above code is only provided for testing purpose and does not intended to be used with production environment unless you have tested it on your end.

NOTE: It is required to map the IAM user/role in the backend roles of Kibana/dashboards by navigating to Security > Roles > for e.g. all_access role > Mapped users.
[+] Fine-grained access control in Amazon OpenSearch Service - Mapping roles to users - Fine-grained access control in Amazon OpenSearch Service - Amazon OpenSearch Service