[BUG] OAUTH2.0 Access Token to access Opnesearch Cluster from an API

[ramizraza504]

What is the bug?
Since the last update done on 2.8 version to include audience and issuer check I was hoping to get our APIs authenticate with opensearch cluster using oauth2.0 access token generated from our IDP but now I am blocked by another possible bug where opensearch cluster OIDC setup is expecting Subject Key which I have configured as Preferred Name and which won't be available for access token generated from a system using client credential flow. If I remove the entry of Subject Key from cluster config then my Dashboard gets messed up with alphanumric auto generated subject key as profile name. This is one issue. Another issue is related where Dashboard generates and send ID Token to cluster rather access token due to which I cannot configure my Opensearch cluster with a different resource server id and have to use same id I used in dashboard because the audience won't match of id token. If Dashboard would have sent access token to cluster then problem would have been solved where my cluster will act as resource server with its own id and dahboard will be a UI client and my API will be another client both having permission with right role/scope of cluster resource server id.

How can one reproduce the bug?
Dashboard configure with an UI registration with your IDP
Cluster configure with Another ID as resource server
API to access cluster directly using access token generated by a client id having permission to resource server of cluster
Subject Key issue is self explanatory I assume.

What is the expected behavior?
To achiever OIDC and OAUTH2.0 flow working for Dashboard and API calling cluster directly using client credential flow

[stephen-crawford]

[Triage] Hi @ramizraza504, thank you for filing this issue. Currently, we do not directly support OAUTH 2.0. Instead, we support OIDC. As a result, you would need to provide further information around which IdP you are using in order to determine which side the issue is occurring on. If you could please provide the additional details that would be appreciated.

Could you also restate the second issue you found--listed in the lower portion of your paragraph? It sounds like you may be using OpenSearch to generate a token for another cluster?

[ramizraza504]

@scrawfor99 Thanks for your response.
I am using Azure AD(EntraID) as our IDP. Also we wanted system to system authentication where user is not involved. I was unable to find a proper way to implement this and hence have to use basic auth for system to system i.e microservice calling opensearch cluster to query data.

For 2nd issue I was asking about opensearch dashboard which uses OIDC credentials/configuration to generate token which gets forwarded to Opensearch cluster is ID Token. However expected behavior was Dashboard itself will use ID Token to populate user info in profile etc but should be forwarding access token to Opensearch cluster for authentication and authorization of the user with roles.
Hope I am clarifying the issue here and not making it more confusing :)

[ramizraza504]

Hello
Just trying to follow up on this. Let me know if any more details is required to help.

[stephen-crawford]

@cwperks can you follow up on this?

[cwperks]

Hey @ramizraza504 , would it be possible to configure a jwt auth backend for this use case?

i.e. https://opensearch.org/docs/latest/security/authentication-backends/jwt/#configuring-jwts

jwt_auth_domain:
  http_enabled: true
  transport_enabled: false
  order: 0
  http_authenticator:
    type: jwt
    challenge: false
    config:
      jwks_uri: "<jwks_uri>"
      subject_key: null
      roles_key: null
      required_audience: aud
      required_issuer: iss
  authentication_backend:
    type: noop

[ramizraza504]

Hey @ramizraza504 , would it be possible to configure a jwt auth backend for this use case?

i.e. https://opensearch.org/docs/latest/security/authentication-backends/jwt/#configuring-jwts

jwt_auth_domain:
  http_enabled: true
  transport_enabled: false
  order: 0
  http_authenticator:
    type: jwt
    challenge: false
    config:
      jwks_uri: "<jwks_uri>"
      subject_key: null
      roles_key: null
      required_audience: aud
      required_issuer: iss
  authentication_backend:
    type: noop

Interesting... I have not seen this documentation before. Is this new ? So we don't need signing key anymore ?. I can definitely try this and see if it can fit our use case. Thanks.

[cwperks]

Yes, its relatively new. It was included since 2.8.0. It was introduced in this PR: #2808