OpenSearch Dashboards returning 401 error when using Keycloak as IDP

jennyglidewell · December 19, 2022, 2:40pm

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
I have tried this in docker and am getting the same error but I most recently am trying the windows installs.
OpenSearch: opensearch-2.4.0
OpenSearch Dashboards: opensearch-dashboards-2.4.1
Keycloak: Using docker image: jboss/keycloak:14.0.0

Note:
Keycloak is running on localhost:8080 (http)
OpenSearch is running on localhost:9200 (https)
OpenSearch dashboards is running on localhost:5601 (http)

Describe the issue:
This is a POC that I am working on. I am simply trying to get OpenSearch Dashboards integrated with Keycloak. When accessing the OpenSearch Dashboards URL: “http://localhost:5601” I am routed to the Keycloak login page to enter my credentials. After entering the credentials for my user I am authenticated successfully through Keycloak and redirected back to the OpenSearch dashboards URL. This is what my URL looks like after redirecting:

localhost:5601/auth/openid/login?state=-vDs8G9IUJveTjRIVedk-W&session_state=109b6744-4e8a-4042-9e1a-de68bbd7e080&code=a42de9ff-cae7-4c4f-8e1f-543b1a07a138.109b6744-4e8a-4042-9e1a-de68bbd7e080.3c9e5a79-de96-4c0f-bc93-0bfeda51090b

I have created these same roles within OpenSearch dashboards and the necessary index pattern within OpenSearch dashboards.

How can I see if Keycloak is sending over the proper roles to OpenSearch Dashboards?

Configuration:
Here are my config.yml and opensearch_dashboards.yml files:

Relevant Logs or Screenshots:

Can anyone please help me figure out what I am doing wrong in my configuration or how to get more detailed logs so that I can better debug this issue? Thank you in advance!

jennyglidewell · December 19, 2022, 4:03pm

@pablo Here is the post that you requested I publish! Please take a look and let me know if you see any issues. Thanks!

pablo · January 9, 2023, 3:34pm

@jennyglidewell Your role mapper type is User Client Role. You should use User Realm Role.

i.e.

jennyglidewell · January 9, 2023, 8:46pm

Thank you for your reply! I updated my role mapper to now use a mapper type of User Realm Role. However, I am still seeing the 401 error when trying to sign into OpenSearch dashboards using my Keycloak credentials.

Here is the log from OpenSearch after trying to sign in:

Here is the log from OpenSearch dashboards after trying to sign in:

Any other suggestions? Is there a way to enable more detailed logging? Thank you for your help!

pablo · January 17, 2023, 7:26pm

@jennyglidewell Do you get Keycloak’s login screen or do you get 401 straight away?
As far as I’m aware there was an issue with openID logging and the dev team is still working on it.

You have the redirect URL set to http://localhost:5601
Do you run OpenSearch Dashboards locally? Do you access OpenSearch Dashboards with http://localhost:5601?

jennyglidewell · February 3, 2023, 7:08pm

@pablo I am being redirected to the Keycloak login screen, I then login successfully and am redirected back to the OpenSearch dashboards URL (http://localhost:5601/auth/openid/login). Note that this URL does have the session and sessionState parameters added to the end of it by Keycloak as expected. However, it is after this redirect that I am seeing the 401 error appear. I am running OpenSearch dashboards locally at http://localhost:5601. I have also tried creating self signed certificates and running dashboards locally at https://localhost:5601 however, I am facing the same issue when I have tried that.

mikeyGlitz · February 12, 2023, 12:26am

@pablo @jennyglidewell I’m having the same problem. I’m using OpenSearch 2.5.0. I installed OpenSearch using the helm chart. These are my configuration files:

`opensearch-security/config.yml`

_meta:
  type: "config"
  config_version: 2
config:
  dynamic:
    authz: {}
    authc:
      basic_internal_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: intern

      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
              pemtrustedcas_filepath: /usr/share/opensearch/config/root-ca/root.ca.crt
            subject_key: preferred_username
            roles_key: roles
            openid_connect_url: https://host.docker.internal/auth/realms/pantry/.well-known/openid-configuration
        authentication_backend:
          type: noop

`opensearch.yml`

cluster:
  name: opensearch-cluster
  routing:
    allocation:
      disk:
        threshold_enabled: false
network.host: 0.0.0.0
plugins:
  security:
    ssl:
      transport:
        pemcert_filepath: /usr/share/opensearch/config/certs/tls.crt
        pemkey_filepath: /usr/share/opensearch/config/certs/tls.key
        pemtrustedcas_filepath: /usr/share/opensearch/config/certs/ca.crt
        enforce_hostname_verification: false
      http:
        enabled: true
        pemcert_filepath: /usr/share/opensearch/config/certs/tls.crt
        pemkey_filepath: /usr/share/opensearch/config/certs/tls.key
        pemtrustedcas_filepath: /usr/share/opensearch/config/certs/ca.crt
    allow_default_init_securityindex: true
    audit.type: internal_opensearch
    authcz.admin_dn:
      - CN=admin,OU=SSL,O=haus
    enable_snapshot_restore_privilege: true
    check_snapshot_restore_write_privileges: true
    restapi:
      roles_enabled: ["all_access", "security_rest_api_access"]
    system_indices:
      enabled: true
      indices:
        [
          ".opendistro-alerting-config",
          ".opendistro-alerting-alert*",
          ".opendistro-anomaly-results*",
          ".opendistro-anomaly-detector*",
          ".opendistro-anomaly-checkpoints",
          ".opendistro-anomaly-detection-state",
          ".opendistro-reports-*",
          ".opendistro-notifications-*",
          ".opendistro-notebooks",
          ".opendistro-asynchronous-search-response*",
        ]

`opensearch-dashboards.yml`

logging:
  dest: stdout
  verbose: true
server:
  name: dashboards
  host: 0.0.0.0
  ssl:
    enabled: true
    key: /usr/share/dashboards/certs/tls.key
    certificate: /usr/share/dashboards/certs/tls.crt
opensearch_security:
  auth:
    type: ["basicauth", "openid"]
    multiple_auth_enabled: true
  openid:
    connect_url: https://host.docker.internal/auth/realms/pantry/.well-known/openid-configuration
    base_redirect_url: https://localhost:5601
    client_id: opensearch-dashboards
    client_secret: REDACTED
    scope: openid profile email
    header: Authorization
    root_ca: /usr/share/dashboards/root-ca/root.ca.crt
    verify_hostnames: "false"
    trust_dynamic_headers: true
opensearch:
  requestHeadersAllowlist: ["Authorization", "security_tenant"]
  hosts: [ "opensearch-cluster-master" ]
  username: "kibanaserver"
  password: "kibanaserver"
  ssl:
    certificateAuthorities:
      - /usr/share/dashboards/root-ca/root.ca.crt
      - /usr/share/dashboards/certs/ca.crt

I’ve also attempted to hit the opensearch root URL with an auth token generated by keycloak:

curl --location --request GET 'https://opensearch-cluster-master:9200' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer REDACTED'

I get the same error from OpenSearch:

[2023-02-12T00:05:02,088][WARN ][o.o.s.h.HTTPBasicAuthenticator] [opensearch-cluster-master-0] No 'Basic Authorization' header, send 401 and 'WWW-Authenticate Basic'
[2023-02-12T00:05:02,092][WARN ][o.o.s.a.BackendRegistry  ] [opensearch-cluster-master-0] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

I don’t think the issue is Opensearch not receiving authentication details from Dashboards.
I’ve CURL’d my keycloak endpoint from the container and I’m able to get a response:

 curl -kv https://host.docker.internal/auth/realms/pantry/.well-known/openid-configuration
*   Trying 192.168.65.2:443...
* Connected to host.docker.internal (192.168.65.2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Feb 11 00:10:02 2023 GMT
*  expire date: May 12 00:10:02 2023 GMT
*  issuer: CN=root-ca
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x6042410)
> GET /auth/realms/pantry/.well-known/openid-configuration HTTP/2
> Host: host.docker.internal
> user-agent: curl/7.79.1
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200 
< date: Sun, 12 Feb 2023 00:28:48 GMT
< content-type: application/json
< content-length: 5833
< cache-control: no-cache, must-revalidate, no-transform, no-store
< x-xss-protection: 1; mode=block
< x-frame-options: SAMEORIGIN
< referrer-policy: no-referrer
< strict-transport-security: max-age=15724800; includeSubDomains
< x-content-type-options: nosniff
< 
{"issuer":"https://host.docker.internal/auth/realms/pantry","authorization_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/auth","token_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/token","introspection_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/token/introspect","userinfo_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/userinfo","end_session_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/logout","frontchannel_logout_session_supported":true,"frontchannel_logout_supported":true,"jwks_uri":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/certs","check_session_iframe":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/login-status-iframe.html","grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials","urn:ietf:params:oauth:grant-type:device_code","urn:openid:params:grant-type:ciba"],"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public","pairwise"],"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"id_token_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"userinfo_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"request_object_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"response_modes_supported":["query","fragment","form_post","query.jwt","fragment.jwt","form_post.jwt","jwt"],"registration_endpoint":"https://host.docker.internal/auth/realms/pantry/clients-registrations/openid-connect","token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"token_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"introspection_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"introspection_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"authorization_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"authorization_encryption_alg_values_supported":["RSA-OAEP","RSA-OAEP-256","RSA1_5"],"authorization_encryption_enc_values_supported":["A256GCM","A192GCM","A128GCM","A128CBC-HS256","A192CBC-HS384","A256CBC-HS512"],"claims_supported":["aud","sub","iss","auth_time","name","given_name","family_name","preferred_username","email","acr"],"claim_types_supported":["normal"],"claims_parameter_supported":true,"scopes_supported":["openid","microprofile-jwt","web-origins","address","profile","roles","offline_access","email","phone"],"request_parameter_supported":true,"request_uri_parameter_supported":true,"require_request_uri_registration":true,"code_challenge_methods_supported":["plain","S256"],"tls_client_certificate_bound_access_tokens":true,"revocation_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/revoke","revocation_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"revocation_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"backchannel_logout_supported":true,"backchannel_logout_session_supported":true,"device_authorization_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/auth/device","backchannel_token_delivery_modes_supported":["poll","ping"],"backchannel_authentication_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/ext/ciba/auth","backchannel_authentication_request_signing_alg_values_supported":["PS384","ES384","RS384","ES256","RS256","ES512","PS256","PS512","RS512"],"require_pushed_authorization_requests":false,"pushed_authorization_request_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/ext/par/request","mtls_endpoint_aliases":{"token_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/token","revocation_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/* Connection #0 to host host.docker.internal left intact
revoke","introspection_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/token/introspect","device_authorization_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/auth/device","registration_endpoint":"https://host.docker.internal/auth/realms/pantry/clients-registrations/openid-connect","userinfo_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/userinfo","pushed_authorization_request_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/ext/par/request","backchannel_authentication_endpoint":"https://host.docker.internal/auth/realms/pantry/protocol/openid-connect/ext/ciba/auth"}}

pablo · February 13, 2023, 10:24am

@mikeyGlitz Is this Keycloak’s root CA?

mikeyGlitz · February 13, 2023, 2:10pm

With the way that I have Keycloak and OpenSearch set up, there’s a Root CA. Then for the Keycloak and OpenSearch namespaces, they have an intermediary CA which signs the certificates for those namespaces. root.ca.crt is the Root CA cert that signs the intermediaries.

Root CA → Keycloak CA → Keycloak cert
Root CA → OpenSearch CA → OpenSearch cert

I think I have a better understanding of what’s happening.

Dashboards authenticates to Keycloak. This part works as expected
the 401 unauthorized is coming from OpenSearch. Logs aren’t providing too much info, but I suspect there’s a problem with the connection from OpenSearch to Keycloak (which I think OpenSearch needs to validate/authenticate the JWT). Also, there’s no new logs from Keycloak
When I CURL the OpenSearch endpoint with the Authorization header, I get the same error that I do when I try to sign in with Dashboards - “no Authorization header”
Another curious thing (I have multi Auth enabled in Dashboards so I’m able to sign in using basic because OIDC doesn’t work) I see a basic backend, but no OpenID backend in Dashboards

pablo · February 13, 2023, 2:55pm

@mikeyGlitz Have you tried to point to the Keycloak’s certificate instead of RootCA?
Also, does your root.ca.crt contains all three certs (Keycloak, Inter, Root)?

mikeyGlitz · February 13, 2023, 9:06pm

@pablo, I’m left scratching my head. I reset Kubernetes using the Docker Desktop controls and now OpenID backend seems to be working. See the below configuration:

`opensearch_security/config.yml`


_meta:
  type: "config"
  config_version: 2
config:
  dynamic:
    authz: {}
    authc:
      basic_internal_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: intern

      openid_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: openid
          challenge: false
          config:
            openid_connect_idp:
              enable_ssl: true
              verify_hostnames: false
              pemtrustedcas_filepath: /usr/share/opensearch/config/root-ca/root.ca.crt
            subject_key: preferred_username
            roles_key: roles
            openid_connect_url: https://{{ domain_name }}/auth/realms/pantry/.well-known/openid-configuration
        authentication_backend:
          type: noop

`opensearch-dashboards.yml`

  server:
    name: dashboards
    host: 0.0.0.0
    ssl:
      enabled: true
      key: /usr/share/dashboards/certs/tls.key
      certificate: /usr/share/dashboards/certs/tls.crt
  opensearch_security:
    auth.type: openid
    openid:
      connect_url: https://{{ domain_name }}/auth/realms/pantry/.well-known/openid-configuration
      base_redirect_url: https://localhost:5601
      client_id: opensearch-dashboards
      client_secret: {{ os_client_secret.stdout }}
      scope: openid profile email
      header: Authorization
      verify_hostnames: false
      root_ca: /usr/share/dashboards/root-ca/root.ca.crt
      trust_dynamic_headers: "true"
  opensearch:
    requestHeadersAllowlist: ["Authorization", "security_tenant"]
    hosts: [ "opensearch-cluster-master" ]
    username: "kibanaserver"
    password: "kibanaserver"
    ssl:
      certificateAuthorities: /usr/share/dashboards/certs/ca.crt

Just to be clear, I did a full reset of my Docker environment:

docker system prune -f
docker images | grep -v IMAGE | awk '{print $3} | xargs docker rmi

I suspected the reason why it started to work, could have something to do with the Docker image, but it appears that v2.5.0 was pushed 22 days ago.

This is the configuration that I’m using for my client:

Previously, I didn’t have Direct Access Grants, Service Accounts, or Authorization enabled. Are you aware if any of these permissions were needed?

Here are the TLS certificates for reference:

`root.ca.crt`

---
Decoded X509 Certificate:

Subject: CN=root-ca
Subject Alt Name:
	DNS:host.docker.internal
		DNS:svc.cluster.local
		DNS:cluster.local
Issuer:
	CN=root-ca
Infoaccess:
	undefined
Validfrom: Feb 12 17:38:05 2023 GMT
Validto: May 13 17:38:05 2023 GMT
Fingerprint: 72:22:1D:44:44:E7:9B:6C:9B:B7:4E:71:8A:F3:4B:0C:21:FA:66:33
Fingerprint256: 34:19:81:EC:C3:19:23:17:A0:85:BF:FE:A0:33:BB:0E:7E:C9:52:AF:7C:8E:2D:30:EA:90:06:20:01:17:D3:09
Keyusage: undefined
Serialnumbe: CFD9C043CC041FA13709395A9741CA23

X509 Certificate:

-----BEGIN CERTIFICATE-----
MIIBqTCCAVCgAwIBAgIRAM/ZwEPMBB+hNwk5WpdByiMwCgYIKoZIzj0EAwIwEjEQ
MA4GA1UEAxMHcm9vdC1jYTAeFw0yMzAyMTIxNzM4MDVaFw0yMzA1MTMxNzM4MDVa
MBIxEDAOBgNVBAMTB3Jvb3QtY2EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS4
5y+HgzGd9txXAIn/NqbsSe2MwEqHfF4+TaBZIbXFD2kGEgDhapzsVtbIu+8fu3I3
OJ99bvqlhfqx+8YD5EtSo4GGMIGDMA4GA1UdDwEB/wQEAwICpDAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBSInBfujUCaOFxgAHfm1VCG6qwxSjBBBgNVHREEOjA4
ghRob3N0LmRvY2tlci5pbnRlcm5hbIIRc3ZjLmNsdXN0ZXIubG9jYWyCDWNsdXN0
ZXIubG9jYWwwCgYIKoZIzj0EAwIDRwAwRAIgQak+g7G1Mg5pTg+Yve/GWuX21n1D
f4ril0BIrIX+zakCIESmCl0ZO5Aiahlz5wUb7bNHYNvnToVGQr6Qycx+nrsY
-----END CERTIFICATE-----

`keycloak.crt`

---
Decoded X509 Certificate:

Subject: undefined
Subject Alt Name:
	DNS:host.docker.internal
Issuer:
	CN=root-ca
Infoaccess:
	undefined
Validfrom: Feb 12 17:38:08 2023 GMT
Validto: May 13 17:38:08 2023 GMT
Fingerprint: 47:48:D6:44:BD:1A:6B:A7:FE:95:C6:B7:C9:5A:5C:F4:E2:DB:1A:F2
Fingerprint256: 4F:4A:F3:82:9D:DD:97:F5:82:C1:64:35:0A:B3:76:0E:75:B5:CF:C9:98:32:E4:BB:73:8E:E4:9D:55:DF:EB:51
Keyusage: undefined
Serialnumbe: 0118CAA610AD1195B35104792F257ED9

X509 Certificate:

-----BEGIN CERTIFICATE-----
MIICQDCCAeagAwIBAgIQARjKphCtEZWzUQR5LyV+2TAKBggqhkjOPQQDAjASMRAw
DgYDVQQDEwdyb290LWNhMB4XDTIzMDIxMjE3MzgwOFoXDTIzMDUxMzE3MzgwOFow
ADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKSuPwQ0tOG4/lASQLp/
PaUKggylWG7F5Nkt7DKA7ef4Bf/G3VEhRlcwIKX+nLhhKkGmtvxmiLiSZU4lLrp9
duCGxSVIzck4otw3l3fzE0EXDfYQ2iOReneN7lF12RH4PPoaXfiqtBS1KaOP4tS2
WX5+34t+UDLWGb77pRdqqD6fj6w6vBYxdoA/0Ejm8ygYkanm6EqLT5ehaTqlRZOG
Fdzov73rN/znsowsLVRItaTvAKxEUgFnCZk8TpvOtrp3d/G8c2e88fztKIivRJy+
ZrOhCU/+KAPIk1fKvKQdssO3DGVijQLy7VoWnKNu+xvu2fq5PGsxCjoGb2VD9itU
hocCAwEAAaNlMGMwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHwYDVR0j
BBgwFoAUiJwX7o1AmjhcYAB35tVQhuqsMUowIgYDVR0RAQH/BBgwFoIUaG9zdC5k
b2NrZXIuaW50ZXJuYWwwCgYIKoZIzj0EAwIDSAAwRQIgPt7Z6ZnpxbQoqjDR4Jpt
smTCvxfQ4Qk0MPbQTImgp+cCIQCXJNkoxuEt5cl85J9rZae/37vxh2vStA0oYZfN
HlRTmw==
-----END CERTIFICATE-----

The big issue for me now is although I got it to work, I don’t know why

@jennyglidewell FYI I’m using the 19.0.3-legacy image I’m not sure if the newer version contains fixes or improvements which would help you. There was a big announcement back in 2021 where Keycloak was migrating away from Wildfly and using Quarkus going forward (hence the legacy images) - Migrating to Quarkus distribution - Keycloak.

punkovain · August 15, 2023, 3:33pm

Hey there! Sorry for the answering to the old topic.

Probably its got fixed because security index has been recreated.
In docker/k8s image you have to run securityadmin.sh script after changing related settings, that’s mean you have to exec into docker container and execute that script with correct config to populate changes.

Topic		Replies	Views
Opensearch Dashboard is not able to parse keycloak ipv6 url OpenSearch Dashboards security-issue	1	319	October 27, 2023
Opensearch-dashboards OpenID authentication produces error 401 Unauthorized OpenSearch Dashboards troubleshoot , configure , security-issue	10	978	May 10, 2024
OpenSearch Dashboards Integration with Keycloak - Issues with Refresh Tokens OpenSearch Dashboards security-issue	7	41	September 6, 2024
OpenID 401 after node restart Security troubleshoot	9	1066	October 5, 2023
Unable to login through Dashboards, API works OpenSearch Dashboards	15	334	June 21, 2024

OpenSearch Dashboards returning 401 error when using Keycloak as IDP

opensearch-security/config.yml

opensearch.yml

opensearch-dashboards.yml

opensearch_security/config.yml

opensearch-dashboards.yml

root.ca.crt

keycloak.crt

Related Topics

`opensearch-security/config.yml`

`opensearch.yml`

`opensearch-dashboards.yml`

`opensearch_security/config.yml`

`opensearch-dashboards.yml`

`root.ca.crt`

`keycloak.crt`