[Question] Should authz information be provided in a(n) [encrypted] claim inside the access token given to extensions

[cwperks]

In order for extensions to interact with the OpenSearch cluster on-behalf-of a user, the extension will be provided an access token that is issued just-in-time to perform its operations. There is currently an ongoing debate on what is contained in the claims of the JWT and so far the following claims will be included with certainty:

{
  "iss": "<cluster_name>",
  "iat": "<time_of_issuance_in_epoch>",
  "exp": "<time_of_expiration_in_epoch>",
  "sub": "<principal_identifier_token",
  "aud": "extension/{extensionUniqueId}"
}

the dispute needed to be resolved is if authz information needs to be included in the claims as well:

Reasons the authz (roles and backend_roles) should be included are:

1. Many plugins rely on roles and backend_roles to perform roles injection and protect resources created by the plugin respectively
2. The security plugin needs roles to evaluate privileges on the request - this is consistent with existing auth backends that expect roles in the JWT payload for SAML, OIDC and JWT backends. For SAML and OIDC, users are authenticated with the external IdP once and all subsequent requests will use a JWT to authenticate until the session is expired. For SAML and OIDC, these are external identity providers and the users referred to in the JWT created for these backends do not exist as internal users.
3. There is no mechanism to lookup roles information from an external IdP - backend roles from these systems is provided at initial login and afterwards its assumed the JWT has the most up-to-date information.

Proposal 1: Include roles and backend_roles in the claims of the JWT

For this approach these claims would be encrypted by default, but on the extension level could be configured in bwc_plugin_compatibility_mode for extensions that rely on backend_roles. An off-ramp to cut plugin/extension's reliance on backend_roles is being discussed [Provide link to issue here]. In bwc mode, the claims would be unencrypted.

In this model, there is no lookup required when the security plugin receives this access token from an extension. On receipt of the access token, the security plugin will verify the signature of the JWT and decrypt the r (r short for roles) and br (br short for backend_roles) claims. From there it will proceed to authorization as normal.

It is not clear how to do roles lookup if the roles and backend_roles are not included in the token. If these claims are not present and the user is not an internal user, then it would require keeping track of sessions or reaching out to the external identity provider that first authenticated the user.

Proposal 2: Exclude roles and backend_roles from the claims of the JWT

This option is not viable, authenticating backends provide point-in-time versions of the user state that translates into the roles/be roles. If this state information is not persisted and given to the user, it will need to be refreshed on every JIT token request. What was previous 1 request to the authenticating backend per session*, will become N request where N is the number of API calls made with the token. This impact scaling requirements of authenticating backends in a way that is not scalable.

*Session: Authenticating backend tokens presumably expire, depending on how long this is determines how long this concept of session lasts, but its configured by the SAML, ODIC, etc... system not by the Security Plugin.

In this approach, roles and backend_roles could be provided to extensions through the transport layer through another means (in bwc mode), but it will be explicitly deprecated and convey to extensions developers to cut their reliance on these or risk compilation failures when support is officially removed.

The challenge in this approach is how to lookup the authz information when the access token is received by OpenSearch.

Additional Background Info

roles and backend_roles are considered sensitive information and will be kept internal to OpenSearch.

Its not unheard of that some JWTs already issued for OSD are over 4kb.

[cwperks]

@peternied Please add any additional comments if its not covered in the description here.

[peternied]

@cwperks I edited the issue with detail - IMO there is no longer a question, we must include the AuthZ information in the OnBehalfOf token as described in Proposal 1: Include roles and backend_roles in the claims of the JWT.

[cwperks]

Closing this issue as complete. Thank you for updating the description @peternied !