Handling identity in extensions

[peternied]

Inside of OpenSearch identity information was stored in the thread context when the security plugin was in use. With extensions being outside of the OpenSearch project, depending on the thread context for user identity will need to be replaced.

This identity should support the following scenarios:

• Actions on the OpenSearch clusters can be tied to a consistent identity
• Identities cannot be tampered with by an extension
• Identities do not disclose any user information
• Identities cannot be used in perpetuity
• Identities support delegation

Lets us this issue to make proposals and discuss the way this should be managed.

[dbwiddis]

Great questions and I am looking forward to more feedback from the rest of the community!

One additional overarching comment I would like to make is that we should be very precise in our language here. My comments below are in that context.

• Actions on the OpenSearch clusters can be tied to a consistent identity

Agreed, but suggest we be very precise on what is meant by "identity" in this context. For example, "User A authenticated to extension B" may be an identity separate from "User A authenticated to extension C".

• Identities cannot be tampered with by an extension

This sounds a little vague. We need to be more specific in how the extension and its authenticated user are treated.

• Identities do not disclose any user information

"User information" is too vague a term. It's absolutely necessary for me to know enough about the user to know that they have the appropriate access/privilege. I expect we'll have at least a unique user login which often gives a hint to a user's name.

• Identities cannot be used in perpetuity

I'm not sure what this means. I would expect my own personal identity to perpetually refer to me, although the access granted to my identity should never be used in perpetuity. Can we be more specific in what is intended here?

[dbwiddis]

Recommend we use a published standard such as SCIM.

[peternied]

Quick note, I'll coming back to this, I think using user scenarios rather than principles might be an easier way to align. Great questions - you'll get answers.

[dbwiddis]

My thoughts on user scenarios:

1. A user of the foo extension has an existing identity external to OpenSearch and wants to use that.
2. A user of the foo extension does not have an existing identity and needs to create one and then get that authorized by someone
3. A user of the foo extension wishes to remain anonymous, and if the underlying data source is intentionally publicly accessible, the extension functions normally.

I earlier referenced SCIM as a standard we can expect for cross-domain identities. We should also expect to be highly interoperable with OpenID-based identity servers.

Regarding precision, I think we can rely on terms as defined by NIST, e.g., identity (multiple defs, we will need to pick one), authentication, etc.

[peternied]

Regarding precision, I think we can rely on terms as defined by NIST, e.g., identity (multiple defs, we will need to pick one), authentication, etc.

Great idea, lets follow these terms.

---

I am consider these scenarios as OpenSearch is the Identity Provider for the user and the extension is a search request cache:

1. A user of OpenSearch performs an action with a registered extension, the extension has enough information to associate that action to that user.
2. A user of OpenSearch performs an action with a registered extension, the extension makes a request to OpenSearch on that user's behalf with a time to live limit.
   • ...the extension makes a request to OpenSearch on that user's behalf after the time has expired the requests is rejected.
   • ...the extension makes a request to OpenSearch on that user's behalf multiple times, after the first all requests are rejected.
   • ...the extension alters the information and makes a request to OpenSearch on that user's behalf and the request is rejected.

sequenceDiagram
   autonumber
   User ->>+ OpenSearch: Make SearchRequest
   OpenSearch ->>+ CacheExtension: Notify extension
   CacheExtension ->>+ OpenSearch: Check cache for User id 
    Note over OpenSearch: OpenSearch verifies call from extension
   OpenSearch ->>- CacheExtension: Cache Data
   CacheExtension ->>- OpenSearch: SearchRequest Extension response
   OpenSearch ->>- User: Cached search response

To handle these scenarios, I am thinking a JWT based system should be sufficient for these needs. JWT supports signing, claims include subject, expiration that can allow/deny workflows like this. What do you think about this as a basis for our OpenSearch to Extension communication as a replacement for the thread context?

OpenSearch should be available for extensions to act as identity providers - making sure we design identities in such a way they can be used with SCIM.

[dbwiddis]

as OpenSearch is the Identity Provider

I'm not so sure this is accurate. We can assume that the identity is derived/tracked from any of a number of other sources. The key point here is that the data within OpenSearch is tagged appropriately to only allow access to identities from the same source. So the key functionality we need to provide is restricting data access based on identity (user/group) no matter who provides that identity.

I am thinking a JWT based system should be sufficient for these needs.

I agree with going the JWT route, but that's mostly an implementation detail while I'm still trying to think a level above that. User identities are going to be created/stored/administered somewhere, and that doesn't need to be in OpenSearch. But:

1. OpenSearch needs enough information about the user/group identities to appropriately tag data
2. Extensions need to be able to authenticate a user identity to put the appropriate information in the JWT request

[peternied]

The existing problem with the extensions implementation is how provide that was previously passed via thread context to extensions. If we think JWT is the mechanism for extensions to transit this information, we can unblock development with a limited interface, this would give us more time to iron out the high level issue of the responsibilities of identity management in OpenSearch.

To keep the discussing going on Identity Providers, I have created How should OpenSearch allow for extensions to provide authentication? #19 does this seem like a fair way to separate these concerns?

[dbwiddis]

Yes, it makes sense to split the two discussions.

As for JWT, there are security considerations. If we implement it we need to be on top of possible exploits and prevent them. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-07

[dbwiddis]

After digging into the existing implementation for a day or two, I think the correct approach is:

• Near term; use existing authentication methods (as referenced in How should OpenSearch allow for extensions to provide authentication?  #19) with minor changes (such as refactoring User out of the Common Utils (see [FEATURE] Remove the ThreadContext dependency on the User from Common Utils for creating detector #23).). Use these methods to produce SCIM-compatible JSON. (I might suggest the SCIM model is an appropriate replacement for User)
• Use that format along with JWT for authenticated user access via other extensions using REST API
• Request validation will still occur with the existing extension.
• Longer term, expand identity to include support for federation via well known identity servers (we can implement a few of the most common ones, and be open to additional integration by customer request/participation)

[dbwiddis]

Hey @peternied can we close this issue in favor of the tracking issues you have linked above?