[BUG] Unconsumed parameter exception when authenticating with jwtUrlParameter

[cwperks]

What is the bug?

Discovered this bug when analyzing #3949. There is a regression in authentication with the jwtUrlParameter where it fails to consume the parameter and response with illegal_argument_exception: contains unrecognized parameter:

Suite: Test class org.opensearch.security.http.JwtAuthenticationTests
  2> java.lang.AssertionError: Expected status code is '200', but was '400'. Response body '{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"request [/_opendistro/_security/authinfo] contains unrecognized parameter: [token]"}],"type":"illegal_argument_exception","reason":"request [/_opendistro/_security/authinfo] contains unrecognized parameter: [token]"},"status":400}'.
    Expected: <200>
         but: was <400>
        at __randomizedtesting.SeedInfo.seed([100EFB1C515D00AA:4401D6965CA5081E]:0)
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
        at org.opensearch.test.framework.cluster.TestRestClient$HttpResponse.assertStatusCode(TestRestClient.java:422)
        at org.opensearch.security.http.JwtAuthenticationTests.shouldAuthenticateWithJwtTokenInUrl_positive(JwtAuthenticationTests.java:163)

How can one reproduce the bug?

Set up and enable a JWT auth domain with the jwt_url_parameter set. Make any request with a valid token.

What is the expected behavior?

The jwt auth domain should successfully authenticate when jwt_url_parameter is supplied with a valid token.

Do you have any additional context?

The regression was introduced with the HeaderVerifier changes where the HTTP Authenticators are dealing with a lower-level request object than the SecurityRestFilter is where authc was previously being performed. The parameters must be consumed on the RestRequest and not the lower level NettyRequest which is used in the HeaderVerifier.

[stephen-crawford]

[Triage] Hi @cwperks thanks for filing this issue. This looks like a good fix to correct the regression.

[cwperks]

#3975 is now merged. Closing this issue.