[Feature/Identity] Adds Basic Auth mechanism via Internal IdP #4798

DarshitChanpura · 2022-10-14T23:22:12Z

Description

Adds a REST request wrapper to intercept all incoming REST requests and authenticate them via Internal IdP (HTTP only for this PR)

NOTE: This PR does not reject the request if no credentials were present and will proceed as normal. This is intentional.

Issues Resolved

[List any issues this PR will resolve]

Check List

New functionality includes testing.
- All tests pass
New functionality has been documented.
- New functionality has javadoc added
Commits are signed per the DCO using --signoff
Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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.

github-actions · 2022-10-14T23:27:59Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/4725/
CommitID: 01faecd

github-actions · 2022-10-14T23:35:06Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/4727/
CommitID: 5d3277f

github-actions · 2022-10-14T23:43:17Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/4728/
CommitID: 42e8115

github-actions · 2022-10-14T23:44:51Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/4729/
CommitID: 68e4ff3

github-actions · 2022-10-14T23:55:17Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/4732/
CommitID: af1b10f

DarshitChanpura · 2022-10-15T00:00:07Z

A whole bunch of tests are failing because of addition of REST request wrapper (literally a breaking change 😅). Looking into possible solutions to fix those now.

stephen-crawford · 2022-10-25T18:16:36Z

sandbox/libs/authn/src/main/java/org/opensearch/authn/User.java

    @JsonProperty(value = "primary_principal")
-    public StringPrincipal getPrimaryPrincipal() {
+    public StringPrincipal getPrincipal() {


The previous version implied that a subject could have more than one principal (which is true), this one does not imply this. Is this intentional or was this change made since it should only ever be interacting with a specific principal at a time?

stephen-crawford · 2022-10-25T18:17:23Z

sandbox/libs/authn/src/main/java/org/opensearch/authn/User.java

    @JsonProperty(value = "primary_principal")
-    public StringPrincipal getPrimaryPrincipal() {
+    public StringPrincipal getPrincipal() {
        return primaryPrincipal;


May want to rename this to be consistent if you are renaming the function call.

stephen-crawford · 2022-10-25T18:19:26Z

sandbox/libs/authn/src/main/java/org/opensearch/authn/realm/InternalRealm.java

+            } else if (!isAuthenticationSuccessful) {
+                throw new AuthenticationException("Authentication finally failed");
+            }
+        } catch (Throwable e) {


Is this a dead throw?

stephen-crawford · 2022-10-25T18:22:25Z

server/src/main/java/org/opensearch/rest/SecurityRestFilter.java

+     * @return true if authentication was successful, false otherwise
+     * @throws Exception generic exception rethrown in case authenticate method throws an exception
+     */
+    private boolean checkAndAuthenticateRequest(RestRequest request, RestChannel channel, NodeClient client) throws Exception {


Consider splitting this into separate formatting and a authenticated checks--may be easier to provide meaningful exception messages.

stephen-crawford · 2022-10-25T18:23:43Z

server/src/main/java/org/opensearch/rest/SecurityRestFilter.java

+     * @return true if authentication was successful, false otherwise
+     * @throws IOException when an exception is raised writing response to channel
+     */
+    private boolean authenticate(RestRequest request, RestChannel channel, NodeClient client) throws IOException {


See above comment; this method authenticates from within the checkAndAuthenticateRequest -- why not split the two if you already have the separate authenticate method?

github-actions · 2022-11-01T17:14:35Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6087/
CommitID: 529daab
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-01T19:35:21Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6109/
CommitID: d31c129
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-01T20:41:30Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6125/
CommitID: fb823c6
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T15:13:09Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6210/
CommitID: 24da64b
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T15:32:58Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6212/
CommitID: a4ac7cb
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T18:56:27Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6245/
CommitID: 22e4af0
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T19:03:41Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6246/
CommitID: ae17a88
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T19:34:13Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6249/
CommitID: 3b2c871
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-02T19:52:24Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6255/
CommitID: 6a0b40b
Please examine the workflow log, locate, and copy-paste the failure below.
Flakey test?
Iterate to green.

github-actions · 2022-11-03T14:02:52Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6290/
CommitID: 2f2834d
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

github-actions · 2022-11-03T20:09:41Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6322/
CommitID: ce25681
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

github-actions · 2022-11-03T20:14:09Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6323/
CommitID: 61f658d
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

DarshitChanpura · 2022-11-03T20:21:10Z

Gradle check failing due to unrelated issue. Check logs from this build and log from CI build a day ago

Looks like an issue with openJDK installation

DarshitChanpura · 2022-11-04T17:15:14Z

Local run of `./gradlew :server:assemble` is successful:

➜  OpenSearch git:(basic-auth-via-internal-idp) ./gradlew :server:assemble

> Configure project :qa:os
Cannot add task 'destructiveDistroTest.docker' as a task with that name already exists.
=======================================
OpenSearch Build Hamster says Hello!
  Gradle Version        : 7.5.1
  OS Info               : Mac OS X 12.6.1 (x86_64)
  Runtime JDK Version   : 11 (Amazon Corretto JDK)
  Runtime java.home     : /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
  Gradle JDK Version    : 11 (Amazon Corretto JDK)
  Gradle java.home      : /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
  Random Testing Seed   : D442BC7730404DBF
  In FIPS 140 mode      : false
=======================================

> Task :server:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

BUILD SUCCESSFUL in 2m 15s
35 actionable tasks: 12 executed, 6 from cache, 17 up-to-date
➜  OpenSearch git:(basic-auth-via-internal-idp)

github-actions · 2022-11-09T16:11:33Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6680/
CommitID: 080d2be
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

github-actions · 2022-11-09T17:42:53Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6690/
CommitID: 51f0e6c
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

github-actions · 2022-11-09T18:33:00Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/6696/
CommitID: df62a8c
Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
Is the failure a flaky test unrelated to your change?

DarshitChanpura · 2022-11-09T19:02:24Z

Seeing too_long_http_line_exception error on the logs:

 java.lang.AssertionError: Failure at [search/30_limits:98]: the error message was expected to match the provided regex but didn't
    Expected: The length of regex \[1110\] used in the Regexp Query request has exceeded the allowed maximum of \[1000\]\. This maximum can be set by changing the \[index.max_regex_length\] index level setting\.
         but: was "{root_cause=[{type=too_long_http_line_exception, reason=An HTTP line is larger than 4096 bytes.}], type=too_long_http_line_exception, reason=An HTTP line is larger than 4096 bytes.}"
        at __randomizedtesting.SeedInfo.seed([7700579BEDAE21BE:FF54684143524C46]:0)
        at org.opensearch.test.rest.yaml.OpenSearchClientYamlSuiteTestCase.executeSection(OpenSearchClientYamlSuiteTestCase.java:459)
        at org.opensearch.test.rest.yaml.OpenSearchClientYamlSuiteTestCase.test(OpenSearchClientYamlSuiteTestCase.java:432)
        at java.****/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
.....

https://netty.io/4.1/api/io/netty/handler/codec/http/TooLongHttpLineException.html

Possibly related: elastic/elasticsearch#1174

cwperks · 2022-11-09T19:28:18Z

server/src/main/java/org/opensearch/rest/RestController.java

+            try {
+                // support other type of header tokens
+                headerToken = new HttpHeaderToken(authHeader.get());
+                subject = Identity.getAuthManager().getSubject();


I've seen this call in Shiro documentation, but I'm not quite following how this resolves to the correct subject here.

According to Shiro docs:

In almost all environments, you can obtain the currently executing Subject by using org.apache.shiro.SecurityUtils: Subject currentUser = SecurityUtils.getSubject(); The getSubject() call in a standalone application might return a Subject based on user data in an application-specific location, and in a server environment (e.g. web app), it acquires the Subject based on user data associated with current thread or incoming request.

https://shiro.apache.org/subject.html

Will this always resolve to the correct Subject?

yes.. Shiro has its own resource store and it fetches correct subject via ThreadContext.

This is how shiro puts resource into its ThreadContext store:

https://github.com/apache/shiro/blob/main/core/src/main/java/org/apache/shiro/util/ThreadContext.java#L153

According to shiro source, the DefaultSecurityManager uses ThreadContext under the hood: https://github.com/apache/shiro/blob/main/core/src/main/java/org/apache/shiro/SecurityUtils.java#LL54C9-L54C54

This call to get subject might have to do some weird stuff such as inspecting the call stack or thread context, but the pattern should be abstracted for use cases like this. Does that seem viable to you, or is there a way you think we should consider reframing the calls?

I'm not sure I understand the ask here

Signed-off-by: Craig Perkins <[email protected]>

github-actions · 2022-11-21T18:06:31Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7148/
CommitID: 7b7fb72
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

Signed-off-by: Darshit Chanpura <[email protected]>

github-actions · 2022-11-22T17:12:29Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7221/
CommitID: c14ab0c
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

DarshitChanpura · 2022-11-29T16:07:06Z

@cwperks @peternied Can you please review and merge this is there is nothing else?

peternied

There are many build errors, please revert the broad chances to the namespace under server/src/... until these are resolved

peternied · 2022-11-29T19:23:04Z

sandbox/libs/authn/build.gradle

@@ -18,7 +18,7 @@ dependencies {
  implementation "com.fasterxml.jackson.core:jackson-annotations:${versions.jackson}"
  implementation "com.fasterxml.jackson.core:jackson-databind:${versions.jackson_databind}"

-  implementation 'org.apache.shiro:shiro-core:1.9.1'
+  api 'org.apache.shiro:shiro-core:1.9.1'


I don't think this change is needed, Could you provide the why of switching from implementation to api dependency type?

cwperks · 2022-11-30T16:26:14Z

sandbox/libs/authn/src/main/java/org/opensearch/authn/AuthenticationTokenHandler.java

+        // Malformed AuthHeader strings
+        if (decodedUserNamePassword.length != 2) return null;
+
+        logger.info("Logging in as: " + decodedUserNamePassword[0]);


: is accepted in the password according to this comment in the security plugin codebase: https://github.com/opensearch-project/security/blob/cad7c7201e902aeb711b407648d41d3c55fe7a49/src/main/java/org/opensearch/security/support/HTTPHelper.java#L52-L57

What do you think about creating an issue and finding/implementing a better version of this?

🤞 I would rather pull a small library in for this kind of logic

I will modify the logic to be similar to one that Craig posted above. However, this seems like a good avenue to explore libraries that provide support for this.

peternied · 2022-11-30T16:54:00Z

There are many build errors, please revert the broad chances to the namespace under server/src/... until these are resolved

🤦‍♂️ My build was not clean, I'll review more deeply...

cwperks · 2022-11-30T17:20:08Z

@DarshitChanpura Thank you for adding tests. Can you please answer @peternied's question on why the change from api to implementation for the shiro dependency is needed.

I am ok with accepting and merging this change and addressing some of the other comments as follow-ups. From what I can see this is what is remaining:

~~How to reject a request without bringing down the cluster~~ - Resolved by skipping dispatchRequest when the request is not authenticated.
Add same scenario tests for username/password combos as security plugin to ensure it works with the same set of rules

I'd be curious to see if we can follow a similar RestWrapper pattern for basic and bearer auth handling. In the current model, core has an extension point called getRestHandlerWrapper (

OpenSearch/server/src/main/java/org/opensearch/plugins/ActionPlugin.java

Lines 130 to 153 in c7ba253

    
               /** 
        
                * Returns a function used to wrap each rest request before handling the request. 
        
                * The returned {@link UnaryOperator} is called for every incoming rest request and receives 
        
                * the original rest handler as it's input. This allows adding arbitrary functionality around 
        
                * rest request handlers to do for instance logging or authentication. 
        
                * A simple example of how to only allow GET request is here: 
        
                * <pre> 
        
                * {@code 
        
                *    UnaryOperator<RestHandler> getRestHandlerWrapper(ThreadContext threadContext) { 
        
                *      return originalHandler -> (RestHandler) (request, channel, client) -> { 
        
                *        if (request.method() != Method.GET) { 
        
                *          throw new IllegalStateException("only GET requests are allowed"); 
        
                *        } 
        
                *        originalHandler.handleRequest(request, channel, client); 
        
                *      }; 
        
                *    } 
        
                * } 
        
                * </pre> 
        
                * 
        
                * Note: Only one installed plugin may implement a rest wrapper. 
        
                */ 
        
               default UnaryOperator<RestHandler> getRestHandlerWrapper(ThreadContext threadContext) { 
        
                   return null; 
        
               }

) that is only allowed to be registered once. It is the extension point used by the security plugin to filter requests and apply authcz on the rest request. The registered wrapper is then applied to the restHandler here: https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/rest/RestController.java#L207

As far as I can see, there is nothing preventing us from applying multiple wrappers. @peternied @DarshitChanpura What do you think about creating a wrapper in the sandbox/lib/opensearch-authn and applying the wrapper first. i.e.

protected void registerHandler(RestRequest.Method method, String path, RestHandler handler) {
        if (handler instanceof BaseRestHandler) {
            usageService.addRestHandler((BaseRestHandler) handler);
        }
        UnaryOperator<RestHandler> authHandlerWrapper = ...; // import the handler from opensearch-authn
        RestHandler wrappedHandler = authHandlerWrapper.apply(handler);
        registerHandlerNoWrap(method, path, handlerWrapper.apply(wrappedHandler));
    }

and we can handle the rest filtering there as its done in the plug-in model? I'm not positive if the location of the authenticate call in this PR is the appropriate place to put the call and by creating a wrapper we know that it will behave similarly to how its working now.

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura · 2022-11-30T19:59:39Z

Can you please answer @peternied's question on why the change from api to implementation for the shiro dependency is needed.

I did. Check this out: #4798 (comment)

How to reject a request without bringing down the cluster

I will look into this as a follow-up to this PR.

Add same scenario tests for username/password combos as security plugin to ensure it works with the same set of rules

Done. I have modified handleBasicAuth method to follow same rules as security plugin

@peternied @DarshitChanpura What do you think about creating a wrapper in the sandbox/lib/opensearch-authn and applying the wrapper first... we can handle the rest filtering there as its done in the plug-in model

I like this idea. I have an abandoned branch where I experimented with a "filter" for rest requests. It needs some modifications but is ready to go. Check this out: https://github.com/DarshitChanpura/OpenSearch/blob/basic-auth-with-security-rest-filter/server/src/main/java/org/opensearch/rest/SecurityRestFilter.java

I'm not positive if the location of the authenticate call in this PR is the appropriate place to put the call and by creating a wrapper we know that it will behave similarly to how its working now.

I'm positive that this is in the correct place, as dispatchRequest checks for content validity and circuitBreaker configuration amongst other things before proceeding to hand it over to the request handler. And since authentication should happen before this and after request validation (which happens in tryAllHandlers method), I believe that this check is in correct place.

github-actions · 2022-11-30T20:16:07Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7457/
CommitID: 1ab5c96
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

cwperks

Thank you @DarshitChanpura! This is a good step forward for security in core.

…ests with no headers to pass-through for time being Signed-off-by: Darshit Chanpura <[email protected]>

github-actions · 2022-12-01T05:55:53Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7473/
CommitID: 4b0aa3a
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

Signed-off-by: Darshit Chanpura <[email protected]>

… and adds a sample user in example users yml Signed-off-by: Darshit Chanpura <[email protected]>

github-actions · 2022-12-01T16:24:11Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7497/
CommitID: aac8bfd
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

Signed-off-by: Darshit Chanpura <[email protected]>

stephen-crawford · 2022-12-01T17:50:55Z

This seems like it is in a good spot. Once this is merged, I will take the bearer auth stuff, and close the draft I have open to make a new PR to introduce bearer auth on top of this. That will give us bearer & basic auth and then we can go from there.

github-actions · 2022-12-01T18:00:33Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7501/
CommitID: 4848e59
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

Signed-off-by: Darshit Chanpura <[email protected]>

github-actions · 2022-12-01T20:03:27Z

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/7513/
CommitID: a747867
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

peternied · 2022-12-01T20:52:06Z

DC I know there are failures, I'm going to merge this change as is and you can keep working on them separately.

DarshitChanpura force-pushed the basic-auth-via-internal-idp branch from 5d3277f to 42e8115 Compare October 14, 2022 23:32

stephen-crawford reviewed Oct 25, 2022

View reviewed changes

DarshitChanpura force-pushed the basic-auth-via-internal-idp branch from ce25681 to 61f658d Compare November 3, 2022 20:12

DarshitChanpura force-pushed the basic-auth-via-internal-idp branch from 61f658d to 080d2be Compare November 9, 2022 16:03

cwperks reviewed Nov 9, 2022

View reviewed changes

Experiment with creating internal realm in OS

eae97da

Signed-off-by: Craig Perkins <[email protected]>

Fixes precommit failures

c14ab0c

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura force-pushed the basic-auth-via-internal-idp branch from 7b7fb72 to c14ab0c Compare November 22, 2022 16:57

stephen-crawford mentioned this pull request Nov 23, 2022

[Feature/Identity] Bearer auth via internal idp #5367

Closed

6 tasks

peternied requested changes Nov 29, 2022

View reviewed changes

cwperks reviewed Nov 30, 2022

View reviewed changes

Updates username-password rules to be same as security plugin

1ab5c96

Signed-off-by: Darshit Chanpura <[email protected]>

cwperks approved these changes Nov 30, 2022

View reviewed changes

Updates RestController to reject unauthorized requests and allow requ…

4b0aa3a

…ests with no headers to pass-through for time being Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura added 3 commits December 1, 2022 11:01

Renames auth tests to have IT extension since its a rest test case

5ac1c09

Signed-off-by: Darshit Chanpura <[email protected]>

Register authn tests to integTest task

5faad80

Signed-off-by: Darshit Chanpura <[email protected]>

Updates ReindexFromRemoteWithAuthTests.java to accomodate native auth…

aac8bfd

… and adds a sample user in example users yml Signed-off-by: Darshit Chanpura <[email protected]>

Adds test_user used by other ITs in example_users yml

4848e59

Signed-off-by: Darshit Chanpura <[email protected]>

Sets Threadleakscop to none for reindex remote auth tests

a747867

Signed-off-by: Darshit Chanpura <[email protected]>

peternied merged commit acb5e4d into opensearch-project:feature/identity Dec 1, 2022

DarshitChanpura mentioned this pull request Dec 3, 2022

[Feature/Identity] Fixes test failures in gradle check for #4798 #5441

Closed

6 tasks

cwperks mentioned this pull request Dec 15, 2022

[Feature/Identity] Merge remote-tracking branch 'origin/main' into feature/identity #5581

Merged

6 tasks

DarshitChanpura mentioned this pull request Jan 11, 2023

[META] Identity in OpenSearch #5834

Open

35 tasks

[Feature/Identity] Adds Basic Auth mechanism via Internal IdP #4798

[Feature/Identity] Adds Basic Auth mechanism via Internal IdP #4798

Conversation

DarshitChanpura commented Oct 14, 2022 • edited Loading

Description

Issues Resolved

Check List

github-actions bot commented Oct 14, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Oct 14, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Oct 14, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Oct 14, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Oct 14, 2022

Gradle Check (Jenkins) Run Completed with:

DarshitChanpura commented Oct 15, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Nov 1, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 1, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 1, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 2, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 3, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 3, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 3, 2022

Gradle Check (Jenkins) Run Completed with:

DarshitChanpura commented Nov 3, 2022

DarshitChanpura commented Nov 4, 2022

github-actions bot commented Nov 9, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 9, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 9, 2022

Gradle Check (Jenkins) Run Completed with:

DarshitChanpura commented Nov 9, 2022 • edited Loading

Choose a reason for hiding this comment

DarshitChanpura Nov 9, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Nov 21, 2022

Gradle Check (Jenkins) Run Completed with:

github-actions bot commented Nov 22, 2022

Gradle Check (Jenkins) Run Completed with:

DarshitChanpura commented Nov 29, 2022

peternied left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peternied commented Nov 30, 2022

cwperks commented Nov 30, 2022 • edited Loading

DarshitChanpura commented Nov 30, 2022

github-actions bot commented Nov 30, 2022

Gradle Check (Jenkins) Run Completed with:

cwperks left a comment

Choose a reason for hiding this comment

DarshitChanpura commented Oct 14, 2022 •

edited

Loading

DarshitChanpura commented Nov 9, 2022 •

edited

Loading

DarshitChanpura Nov 9, 2022 •

edited

Loading

cwperks commented Nov 30, 2022 •

edited

Loading