[Question] What capabilities should a token that is passed to an extension have? Should it be a JWT?

[peternied]

This issue should be used for detailing the options for the tokens that will be passed to extensions. This issue should have a comparison of the options and justifications for a decision.

1. Restate problem
2. List capabilities required.
3. Make a T-chart with pros and cons of options and check off capabilities.
4. Say best one.

[RyanL1997]

Token Based Authentication for Extensions

Problem

The plugins can interact opensearch as the user. However, extensions do not have this capability. Extensions need a way to perform actions as the users. For achieving this, the extensions require token to make a request against opensearch cluster as the user.

List capabilities/required - How is that token used?

1. Generated by security plugin
2. Included pass by Extension Rest Handler to extensions
3. Once it got passed, the extensions will store/used the token
   1. The extension should not be able to modify the token
   2. The extension should/should not(?) be able to read the content of the token
   3. For one requests, the token can be reused multiple times as the user
   4. The token will be expired once the client request is done

4. When OS gets called by the token, it will act like a user, and the token identifies where that request comes from

Pro/Cons

Option 1: JWT

One of the most common solutions used for representing claims that are to be transferred between two parties. JWT consists of three parts separated by dots: a header, a payload, and a signature. Payload contains the actual claims being transferred. The signature is used to verify the integrity of the token.

Pros:

• JWT is already implemented in Security Plugin/Feature Identity
• JWT supports tamper protection/expiration
• JWT typically has smaller size, since it doesn’t include encryption

Cons:

• Even JWT is using digital signature to verify its authenticity, its payload can be viewed by extension, we may need extra encryption to secure sensitive user information before we cross the trust boundary.
• Payload size is limited

Option 2: JWE

JWE is commonly used for encrypting a payload so that it can be securely transmitted between two parties. JWE Consists of five parts separated by dots: a header, a payload, a ciphertext, an initialization vector (IV), authentication tag, and optionally an encrypted key. The header contains information about the encrypted data. The IV is used to randomize the encryption and the authentication tag is used to verify the integrity of the data.

Pros:

• Encrypts the payload so that it can be transmitted securely between two parties.
• Supports encryption and decryption of data
• Supports multiple encryption algorithms

Cons:

• More complex to implement
• JWE is larger in size than JWT due to the inclusion of encryption
• Requires key management to be handled securely
• May impact performance due to encryption and decryption overhead

Appendix

Steps we need if we choose Option1:

1. Create the generation method of the token
   1. Example in Identity: https://github.com/opensearch-project/OpenSearch/blob/feature/identity/sandbox/modules/identity/src/main/java/org/opensearch/identity/jwt/JwtVendor.java
   2. Example in Security Plugin (SAML): https://github.com/opensearch-project/security/blob/main/src/main/java/com/amazon/dlic/auth/http/saml/AuthTokenProcessorHandler.java#L290
2. Make the JWK (json web key) configurable via setting
3. Build the extension point in core: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/extensions/rest/RestSendToExtensionAction.java#L164

What need to be carried in the payload?

Since the purpose of this token is to make extension act like a user, no matter which option we choose, the payload should carry the user informations. According to the above comparison between JWT and JWE, the biggest difference is coming from the processing of sensitive information. Therefore, it is necessary for us to reach a consensus on what user informations is sensitive (backend roles, etc.).

Nested JWT

JWE allows you to encrypt any arbitrary payload; however, a common use case is for the payload to be another JWT. This is known as a Nested JWT. Here is the documentation of JWT Framework: https://web-token.spomky-labs.com/advanced-topics-1/nested-tokens

Steps to encrypt the payload of a JWT:

1. Construct the JWT token with the payload in the usual way, but no sign it yet.
2. Create a JWE header that specifies the encryption algorithm, key encryption algorithm, and key to be used for encryption.
3. Encrypt the JWT payload using the specified encryption algorithm and key.
4. Create a new JWT token with the JWE header as the header, the encrypted payload as the body, and an empty signature as the signature.
5. Transmit the JWE-encrypted JWT token to the receiver.
6. The receiver can then decrypt the payload using the specified algorithm and key, and validate the signature of the original JWT

[peternied]

Moving forward starting with a JWT tokens, having clients treat them as opaque strings. Then we can transition to JWE without blocking the authentication workflow.

Note; I would like for the security plugin to quickly migrate to JWE so we are enforcing opaque nature of the tokens.

@opensearch-project/security Does anyone have other thoughts or should we consider this closed?

[RyanL1997]

Summary of the Solution

The security team has opted to employ a just-in-time (JIT) token for managing authentication requests between the user's client and the extension. This token's payload claims must encompass all standard JWT token configurations while incorporating encrypted roles and backend_roles claims. OpenSearch will be responsible for handling the encryption and decryption processes. This approach ensures the protection of user information, even when traversing trust boundary.

Closing this issue now. For the further discussion of authentication backend and extension's security configuration, more discussions can be found here: #2619, #2616