Sorry, again, Anya … I really mean it this time. Restart your ‘no posting about computer stuff’ timer!
I was able to cobble together a functional configuration to authenticate users through an OpenID identity provider. This approach combined the vendor documentation, ten different forum posts, and some debugging of my own. Which is to say … not immediately obvious.
Importantly, you can enable debug logging on just the authentication component. Trying to read through the logs when debug logging is set globally is unreasonable. To enable debug logging for JWT, add the following to config/log4j2.properties
logger.securityjwt.name = com.amazon.dlic.auth.http.jwt logger.securityjwt.level = debug
On the OpenSearch Dashboard server, add the following lines to ./opensearch-dashboards/config/opensearch_dashboards.yml
opensearch_security.auth.type: "openid" opensearch_security.openid.connect_url: "https://IdentityProvider.example.com/.well-known/openid-configuration" opensearch_security.openid.client_id: "<PRIVATE>" opensearch_security.openid.client_secret: "<PRIVATE>" opensearch_security.openid.scope: "openid " opensearch_security.openid.header: "Authorization" opensearch_security.openid.base_redirect_url: "https://opensearch.example.com/auth/openid/login"
On the OpenSearch servers, in ./config/opensearch.yml, make sure you have defined plugins.security.ssl.transport.truststore_filepath
While this configuration parameter is listed as optional, something needs to be in there for the OpenID stuff to work. I just linked the cacerts from our JDK installation into the config directory.
If needed, also configure the following additional parameters. Since I was using the cacerts truststore from our JDK, I was able to use the defaults.
|plugins.security.ssl.transport.truststore_type||The type of the truststore file, JKS or PKCS12/PFX. Default is JKS.|
|plugins.security.ssl.transport.truststore_alias||Alias name. Optional. Default is all certificates.|
|plugins.security.ssl.transport.truststore_password||Truststore password. Default is changeit.|
Configure the openid_auth_domain in the authc section of ./opensearch/config/opensearch-security/config.yml
openid_auth_domain: http_enabled: true transport_enabled: true order: 1 http_authenticator: type: "openid" challenge: false config: openid_connect_idp: enable_ssl: true verify_hostnames: false openid_connect_url: https://idp.example.com/.well-known/openid-configuration authentication_backend: type: noop
Note that subject_key and role_key are not defined. When I had subject_key defined, all user logon attempts failed with the following error:
[2022-09-22T12:47:13,333][WARN ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [UOS-OpenSearch] Failed to get subject from JWT claims, check if subject_key 'userId' is correct. [2022-09-22T12:47:13,333][ERROR][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [UOS-OpenSearch] No subject found in JWT token [2022-09-22T12:47:13,333][WARN ][o.o.s.h.HTTPBasicAuthenticator] [UOS-OpenSearch] No 'Basic Authorization' header, send 401 and 'WWW-Authenticate Basic'
Finally, use securityadmin.sh to load the configuration into the cluster:
/opt/opensearch-2.2.1/plugins/opensearch-security/tools/securityadmin.sh --diagnose -cd /opt/opensearch/config/opensearch-security/ -icl -nhnv -cacert /opt/opensearch-2.2.1/config/certs/root-ca.pem -cert /opt/opensearch-2.2.1/config/certs/admin.pem -key /opt/opensearch-2.2.1/config/certs/admin-key.pem -h UOS-OpenSearch.example.com
Restart OpenSearch and OpenSearch Dashboard — in the role mappings, add custom objects for the external user IDs.
When logging into the Dashboard server, users will be redirected to the identity provider for authentication. In our sandbox, we have two Dashboard servers — one for general users which is configured for external authentication and a second for locally authenticated users.