Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling identity in extensions #14

Closed
peternied opened this issue Jun 13, 2022 · 10 comments
Closed

Handling identity in extensions #14

peternied opened this issue Jun 13, 2022 · 10 comments
Labels
discuss help wanted Extra attention is needed

Comments

@peternied
Copy link
Member

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.

@peternied peternied added help wanted Extra attention is needed untriaged labels Jun 13, 2022
@dbwiddis
Copy link
Member

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
Copy link
Member

Recommend we use a published standard such as SCIM.

@peternied
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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
Loading

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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

@dbwiddis
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants