-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[Feature/Extensions] Principal identity for Opensearch requests to/from extensions #4299
[Feature/Extensions] Principal identity for Opensearch requests to/from extensions #4299
Conversation
Gradle Check (Jenkins) Run Completed with:
|
1671cac
to
d15b1a1
Compare
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Hey @DarshitChanpura thanks for this draft PR. Some quick feedback that should hopefully help you iterate:
|
Continuing on the above comment, the
Later the extension will send this key back with a different request or transport, and you can look up the |
As far as storing in the map, if you go with Apache Shiro, it looks like the RememberMeManager is probably built for this purpose. Not sure if the token it produces is an "access token" but worth looking into. |
Finally comment for today: where to put the map? I'd suggest a brand new object somewhere. Look in Node.java where a lot of individual objects are instantiated, such as the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting this out there and forwarding the discussion around our identities!
/* A non-unique human readable identifier */ | ||
String getUserName(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should an extension be able to know a human readable identifier?
If we are being privacy focused - no seems like the answer. Get access to user data such as there name should involve a permission that must be requested.
If this Principal is be used as a cache key, then we wouldn't want fields that could change - would the username as well as the other fields be consistent or do they store mutable data? I like the notion from Shiro of a principal collection (mutable) being composed of immutable principals.
If we want to simplify calling patterns, less back/forth for often used data can offer big gains in roundtrip impact.
For me, a separate set of APIs for getting identity information limits the amount of work we need to do in the moment and removes assumptions from extensions implementations.
@dbwiddis What do you think about the role of this object, be more user property bag focused or identity token? What scenarios are more important for extensions writers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm following SCIM definition. However this implementation is open to suggestions and changes
|
||
protected final static class AnonymousIdentity extends Identity { | ||
// TODO: Determine risk of collision when generating random UUID | ||
private final static UUID ID = new UUID(0L, 0L); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be an non-zero constant value, new UUID(0x817a6e, 0x817a6e)
would be a quirky entry. Inspired by @dbwiddis comment #4028 (comment)
/* Contains principal type definition */ | ||
List<String> getSchemas(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have an example of what kind of data would be in here?
String getUserName(); | ||
|
||
/* Contains metadata relevant to entity*/ | ||
Map<String, String> getMetaData(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of data would we store in here? I would prefer strong types when possible to avoid blind gets/casts, but maybe we need it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refer this comment: #4028 (comment)
@@ -24,49 +26,57 @@ | |||
*/ | |||
public class RegisterRestActionsRequest extends TransportRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would want similar treatment on any request from OpenSearch -> Extension interactions - should a there be a base class for all interactions, or a common wrapper? @saratvemulapalli have you had thoughts about this space?
Making this more concrete, lets consider the IndicesModuleRequest.
IndicesModuleRequest is translated by ExtensionsOrchestrator to send the request to the Extension (ExtensionRunner). When the call is send off to the extension, the identity of the operation should be included. Attaching this information onto of the Request
object seems most straight forward, but is there another way that would better integrate it?
This would also mean that before transiting the OpenSearch -> Extension boundary there would be some kind of 'get current identity and associate it as a Principle with outbound request' component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peternied Absolutely, as we are working through the security features I think we should start implementing generic message handler which mandates including node identity, security identity etc.
May be lets start opening up an issue ?
// TODO: Determine how this principal can be shared between threads and | ||
// the effects of extending NamedWriteable class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not certain the implications of using extending NamedWritable - is there a good reference or implementation that I could follow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about that yet.. but you can search for NamedWritable in the codebase. It is for arbitrary seralizable objects. See interface definition here
I believe it should be "Username" and "Metadata" vs. "UserName" and "MetaData". |
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
6eaa76f
to
c28cfd3
Compare
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
f0d6e64
to
abce649
Compare
Gradle Check (Jenkins) Run Completed with:
|
da6ac4a
to
e86cc10
Compare
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
f0b5755
to
00e2683
Compare
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
server/src/main/java/org/opensearch/extensions/rest/RestSendToExtensionAction.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/opensearch/extensions/rest/RestSendToExtensionAction.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/opensearch/identity/ExtensionPrincipalsRegistry.java
Outdated
Show resolved
Hide resolved
Gradle Check (Jenkins) Run Completed with:
|
dd41e8a
to
f24bb48
Compare
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Signed-off-by: Peter Nied <[email protected]>
Signed-off-by: Peter Nied <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
… to correct registry Signed-off-by: Darshit Chanpura <[email protected]>
…s a few PR comments Signed-off-by: Darshit Chanpura <[email protected]>
…ate token correctly Signed-off-by: Darshit Chanpura <[email protected]>
a92488c
to
4a4c533
Compare
Gradle Check (Jenkins) Run Completed with:
|
Pre-commit task failed with unable to resolve netty dependencies. Unable to reproduce it locally. Update: Resolved on its own |
Gradle Check (Jenkins) Run Completed with:
|
Signed-off-by: Darshit Chanpura <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
Signed-off-by: Darshit Chanpura <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
Build failed with this:
Probably need to re-trigger the check |
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Codecov Report
@@ Coverage Diff @@
## feature/extensions #4299 +/- ##
========================================================
+ Coverage 70.57% 70.72% +0.14%
- Complexity 57370 57527 +157
========================================================
Files 4642 4644 +2
Lines 276302 276347 +45
Branches 40389 40394 +5
========================================================
+ Hits 195012 195446 +434
+ Misses 64936 64557 -379
+ Partials 16354 16344 -10
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall the changes look good to me. @DarshitChanpura thanks for this start.
Dropped a couple of questions but it shouldn't be blocking the merge.
@@ -16,6 +16,7 @@ Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) | |||
- Update previous release bwc version to 2.4.0 ([#4455](https://github.com/opensearch-project/OpenSearch/pull/4455)) | |||
- 2.3.0 release notes ([#4457](https://github.com/opensearch-project/OpenSearch/pull/4457)) | |||
- Warn future developers not to pass headers to extensions ([#4430](https://github.com/opensearch-project/OpenSearch/pull/4430)) | |||
- Principal Identity for Opensearch requests to/from extensions ([#4299](https://github.com/opensearch-project/OpenSearch/pull/4299)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you guys plan to get feature/extensions
and feature/identity
to be in sync?
Its going to be pain because you might need changes in feature/extensions
in feature/identity
but they might not work.
* Requester Token for requests to/from an extension | ||
* Each user will have different token for different extension | ||
* | ||
* @opensearch.internal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
opensearch.internal
is used for everything internal to opensearch which is not exposed to plugins/extensions.
@dbwiddis @owaiskazi19 how do you want to name this? (cc: @nknize)
Not a blocker for this PR but I think we need to think about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we create a new javadoc flag and call it as opensearch.extensions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we refactor, I think we would want to call out for both plugins and extensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll create a follow up.
* Token processor class to handle token encryption/decryption | ||
* This processor is will be instantiated for every extension | ||
*/ | ||
public class ExtensionTokenProcessor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very much tied to an extension, do you want to do something more generic which we can use for non-extensions?
Again, not a blocker for this PR. Trying to understand how we could make it better for rest of the use-cases.
Description
Adds a basic identifiers to determine owner for each request from OpenSearch to extensions.
Issues Resolved
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.