{"id":9370,"date":"2022-09-22T19:56:00","date_gmt":"2022-09-23T00:56:00","guid":{"rendered":"https:\/\/www.rushworth.us\/lisa\/?p=9370"},"modified":"2022-09-22T21:10:36","modified_gmt":"2022-09-23T02:10:36","slug":"configuring-opensearch-2-x-with-openid-authentication","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=9370","title":{"rendered":"Configuring OpenSearch 2.x with OpenID Authentication"},"content":{"rendered":"\n

Sorry, again, Anya … I really mean it this time. Restart your ‘no posting about computer stuff’ timer!<\/em><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Importantly, you can enable debug logging on just<\/em> 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<\/p>\n\n\n

\nlogger.securityjwt.name = com.amazon.dlic.auth.http.jwt\nlogger.securityjwt.level = debug\n<\/pre><\/div>\n\n\n
On the OpenSearch Dashboard server, add the following lines to .\/opensearch-dashboards\/config\/opensearch_dashboards.yml<\/p>\n\n\n
\nopensearch_security.auth.type: "openid"\nopensearch_security.openid.connect_url: "https:\/\/IdentityProvider.example.com\/.well-known\/openid-configuration"\nopensearch_security.openid.client_id: "<PRIVATE>"\nopensearch_security.openid.client_secret: "<PRIVATE>"\nopensearch_security.openid.scope: "openid "\nopensearch_security.openid.header: "Authorization"\nopensearch_security.openid.base_redirect_url: "https:\/\/opensearch.example.com\/auth\/openid\/login"\n\n<\/pre><\/div>\n\n\n
On the OpenSearch servers, in .\/config\/opensearch.yml, make sure you have defined plugins.security.ssl.transport.truststore_filepath<\/p>\n\n\n\n
While this configuration parameter is listed as optional, something<\/em> needs to be in there for the OpenID stuff to work. I just linked the cacerts from our JDK installation into the config directory. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
plugins.security.ssl.transport.truststore_type<\/td>The type of the truststore file, JKS or PKCS12\/PFX. Default is JKS.<\/td><\/tr>
plugins.security.ssl.transport.truststore_alias<\/td>Alias name. Optional. Default is all certificates.<\/td><\/tr>
plugins.security.ssl.transport.truststore_password<\/td>Truststore password. Default is changeit.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Configure the openid_auth_domain in the authc section of .\/opensearch\/config\/opensearch-security\/config.yml<\/p>\n\n\n
\n      openid_auth_domain:\n        http_enabled: true\n        transport_enabled: true\n        order: 1\n        http_authenticator:\n          type: "openid"\n          challenge: false\n          config:\n            openid_connect_idp:\n              enable_ssl: true\n              verify_hostnames: false\n            openid_connect_url: https:\/\/idp.example.com\/.well-known\/openid-configuration\n        authentication_backend:\n          type: noop\n\n<\/pre><\/div>\n\n\n
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:<\/p>\n\n\n
\n[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.\n[2022-09-22T12:47:13,333][ERROR][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [UOS-OpenSearch] No subject found in JWT token\n[2022-09-22T12:47:13,333][WARN ][o.o.s.h.HTTPBasicAuthenticator] [UOS-OpenSearch] No 'Basic Authorization' header, send 401 and 'WWW-Authenticate Basic'\n<\/pre><\/div>\n\n\n
Finally, use securityadmin.sh to load the configuration into the cluster:<\/p>\n\n\n
\n\/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\n<\/pre><\/div>\n\n\n
Restart OpenSearch and OpenSearch Dashboard — in the role mappings, add custom objects for the external user IDs. <\/p>\n\n\n\n
When logging into the Dashboard server, users will be redirected to the identity provider for authentication. In our sandbox, we have two<\/em> Dashboard servers — one for general users which is configured for external authentication and a second for locally authenticated users. <\/p>\n","protected":false},"excerpt":{"rendered":"
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 …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1588],"tags":[1590,1591,1488,1742,1740,1741],"class_list":["post-9370","post","type-post","status-publish","format-standard","hentry","category-elk","tag-elasticsearch","tag-kibana","tag-oauth","tag-openid","tag-opensearch","tag-opensearch-dashboard"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9370"}],"version-history":[{"count":2,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9370\/revisions"}],"predecessor-version":[{"id":9373,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/9370\/revisions\/9373"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}