OauthBearer validation filter #1195

callaertanthony · 2024-05-09T23:19:32Z

Type of change

Enhancement / new feature

Description

This pull request has the intention to introduce OauthBearer management into Kroxylicious.
Two ideas for this :

Add a new OauthBearerFilter to check if a token is valid before sending it to upstream.
Re-enable AuthnHandler and add OAUTHBEARER.

Additional Context

OauthBearerFilter is simple and really useful for a Kafka proxy, it helps relieve the upstream kafka when downstream tried too many invalid authentications.If token is valid, it just forward the SASL request to upstream, letting upstream kafka do it again and self manage RBAC.
The second method is to fully delegate the SASL connection to Kroxylicious. Kroxylicious will catch all SASL requests and handle the connection. Then, it uses another self connection to upstream, using this new upstream role.
It requires to have RBAC management I think, otherwise, the use case is just to proxy OAUTHBEARER to ANY connection, loosing the OAUTHBEARER principal user and using another one from the upstream connection (or no one if no authentication configured.
AuthnHandler is more tricky, at this time, it doesn't give the possibility to handle different OAUTHBEARER configs by VirtualCluster, so I think a refactor is required on this part.
Edit : I moved the SASL connection part to another PR : handle OAUTHBEARER SASL connection #1206

Checklist

Please go through this checklist and make sure all applicable tasks have been done

Write tests
Make sure all tests pass
Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
Update documentation
Reference relevant issue(s) and close them after merging
For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

tombentley

This looks like great progress, thank you!

docs/available-filters/oauthbearer/oauthbearer.adoc

tombentley · 2024-05-13T02:51:16Z

kroxylicious-runtime/src/main/java/io/kroxylicious/proxy/internal/KafkaAuthnHandler.java

@@ -742,7 +747,7 @@ else if (offsetFetchRequestData.topics() != null) {
                        .build(apiVersion);
                break;
            case UPDATE_METADATA:
-                req = new UpdateFeaturesRequest((UpdateFeaturesRequestData) reqBody, apiVersion);
+                req = new UpdateFeaturesRequest((UpdateFeaturesRequestData) reqBody, apiVersion); // TODO: check why


If you mean, "why it's not using the builder", I'm not sure there is a reason. Happy to switch to using the builder if it doesn't fail the tests.

When I first read it, I didn't understand why the UPDATE_METADATA returns an UpdateFeaturesRequest rather than an UpdateMetadataRequest ? Is it voluntary ?

docs/available-filters/oauthbearer/oauthbearer.adoc

kroxylicious-filters/kroxylicious-oauthbearer/pom.xml

...ylicious-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearer.java

...ious-oauthbearer/src/test/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerTest.java

...ylicious-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearer.java

...us-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerFilter.java

...ious-oauthbearer/src/test/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerTest.java

k-wall · 2024-05-14T15:23:12Z

This looks really useful to me. I know in a past life, I'd have loved to been able to protect my Kafka Cluster from clients hammering it with duff tokens.

...us-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerFilter.java

...ylicious-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearer.java

tombentley

Thanks again @callaertanthony, I took a closer look and left a few comments. I don't think this is very far from being mergeable.

docs/available-filters/oauthbearer/oauthbearer.adoc

kroxylicious-filters/kroxylicious-oauthbearer/pom.xml

...us-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerFilter.java

...icious-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/SharedContext.java

tombentley · 2024-05-17T02:57:31Z

kroxylicious-filters/kroxylicious-oauthbearer/pom.xml

+                        <id>analyze</id>
+                        <configuration>
+                            <ignoredUnusedDeclaredDependencies>
+                                <ignoredUnusedDeclaredDependency>org.bitbucket.b_c:jose4j</ignoredUnusedDeclaredDependency>


Can you explain how this is actually being used?

This dependency is used by kafka on the token validation, but it is not found by kroxylicious on classpath. We must add it as dependency in the project but we don't directly use it. It's used by the kafka OAuthBearerValidatorCallbackHandler

...us-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerFilter.java

...validation/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidation.java

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java

k-wall

One comment left. There's also one Sonar issue. But otherwise code lgtm.
Can you add an entry into the CHANGLOG?

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java

k-wall · 2024-05-27T14:46:29Z

I ran up a test case using auth0.com as the oauth server. I notice a problem, the token validation is failing (it is an audience issue but the precise detail of the error is unimportant) but the filter is still relaying the SaslAuthenticationRequest to the broker.

I'm seeing this is the logs:

2024-05-27 15:28:08 <KQueueEventLoopGroup-5-1> WARN  org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler:187 - Could not validate the access token: JWT (claims->{"iss":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/","sub":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8@clients","aud":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/","iat":1716820056,"exp":1716906456,"gty":"client-credentials","azp":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8"}) rejected due to invalid claims or other invalid content. Additional details: [[8] Audience (aud) claim [https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/] present in the JWT but no expected audience value(s) were provided to the JWT Consumer. Expected one of [] as an aud value.]
org.apache.kafka.common.security.oauthbearer.internals.secured.ValidateException: Could not validate the access token: JWT (claims->{"iss":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/","sub":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8@clients","aud":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/","iat":1716820056,"exp":1716906456,"gty":"client-credentials","azp":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8"}) rejected due to invalid claims or other invalid content. Additional details: [[8] Audience (aud) claim [https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/] present in the JWT but no expected audience value(s) were provided to the JWT Consumer. Expected one of [] as an aud value.]
	at org.apache.kafka.common.security.oauthbearer.internals.secured.ValidatorAccessTokenValidator.validate(ValidatorAccessTokenValidator.java:158) ~[kafka-clients-3.7.0.jar:?]
	at org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler.handleValidatorCallback(OAuthBearerValidatorCallbackHandler.java:184) ~[kafka-clients-3.7.0.jar:?]
	at org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler.handle(OAuthBearerValidatorCallbackHandler.java:169) ~[kafka-clients-3.7.0.jar:?]
	at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslServer.process(OAuthBearerSaslServer.java:156) ~[kafka-clients-3.7.0.jar:?]
	at org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslServer.evaluateResponse(OAuthBearerSaslServer.java:101) ~[kafka-clients-3.7.0.jar:?]
	at io.kroxylicious.proxy.filter.oauthbearer.OauthBearerValidationFilter.doAuthenticate(OauthBearerValidationFilter.java:172) ~[classes/:?]
	at io.kroxylicious.proxy.filter.oauthbearer.OauthBearerValidationFilter.lambda$authenticate$2(OauthBearerValidationFilter.java:153) ~[classes/:?]
	at io.kroxylicious.proxy.filter.oauthbearer.OauthBearerValidationFilter.schedule(OauthBearerValidationFilter.java:182) ~[classes/:?]
	at io.kroxylicious.proxy.filter.oauthbearer.OauthBearerValidationFilter.authenticate(OauthBearerValidationFilter.java:151) ~[classes/:?]
	at io.kroxylicious.proxy.filter.oauthbearer.OauthBearerValidationFilter.onSaslAuthenticateRequest(OauthBearerValidationFilter.java:108) ~[classes/:?]
	at io.kroxylicious.proxy.filter.SaslAuthenticateRequestFilterInvoker.onRequest(SaslAuthenticateRequestFilterInvoker.java:47) ~[classes/:?]
	at io.kroxylicious.proxy.filter.SpecificFilterArrayInvoker.onRequest(SpecificFilterArrayInvoker.java:649) ~[classes/:?]
	at io.kroxylicious.proxy.filter.SafeInvoker.onRequest(SafeInvoker.java:34) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.dispatchDecodedRequest(FilterHandler.java:224) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.writeDecodedRequest(FilterHandler.java:205) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.write(FilterHandler.java:143) ~[classes/:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:891) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:875) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:984) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:868) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.kroxylicious.proxy.internal.FilterHandler.forwardRequest(FilterHandler.java:341) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.handleRequestFilterResult(FilterHandler.java:271) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.lambda$configureRequestFilterChain$12(FilterHandler.java:233) ~[classes/:?]
	at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:684) ~[?:?]
	at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662) ~[?:?]
	at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2200) ~[?:?]
	at io.kroxylicious.proxy.internal.FilterHandler.configureRequestFilterChain(FilterHandler.java:233) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.writeDecodedRequest(FilterHandler.java:213) ~[classes/:?]
	at io.kroxylicious.proxy.internal.FilterHandler.write(FilterHandler.java:143) ~[classes/:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:891) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:875) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:984) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:868) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.DefaultChannelPipeline.write(DefaultChannelPipeline.java:1015) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannel.write(AbstractChannel.java:301) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.kroxylicious.proxy.internal.KafkaProxyFrontendHandler.forwardOutbound(KafkaProxyFrontendHandler.java:367) ~[classes/:?]
	at io.kroxylicious.proxy.internal.KafkaProxyFrontendHandler.channelRead(KafkaProxyFrontendHandler.java:194) ~[classes/:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:93) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.kroxylicious.proxy.internal.ResponseOrderer.channelRead(ResponseOrderer.java:56) ~[classes/:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) ~[netty-codec-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) ~[netty-codec-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.kqueue.AbstractKQueueStreamChannel$KQueueStreamUnsafe.readReady(AbstractKQueueStreamChannel.java:544) ~[netty-transport-classes-kqueue-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.kqueue.AbstractKQueueChannel$AbstractKQueueUnsafe.readReady(AbstractKQueueChannel.java:387) ~[netty-transport-classes-kqueue-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.kqueue.KQueueEventLoop.processReady(KQueueEventLoop.java:218) ~[netty-transport-classes-kqueue-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.channel.kqueue.KQueueEventLoop.run(KQueueEventLoop.java:296) ~[netty-transport-classes-kqueue-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.109.Final.jar:4.1.109.Final]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.109.Final.jar:4.1.109.Final]
	at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT (claims->{"iss":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/","sub":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8@clients","aud":"https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/","iat":1716820056,"exp":1716906456,"gty":"client-credentials","azp":"8adOD5hy3CBTAYUel6RO54b6M1mvP1W8"}) rejected due to invalid claims or other invalid content. Additional details: [[8] Audience (aud) claim [https://dev-j2kfifzhr0wa7o3h.us.auth0.com/api/v2/] present in the JWT but no expected audience value(s) were provided to the JWT Consumer. Expected one of [] as an aud value.]
	at org.jose4j.jwt.consumer.JwtConsumer.validate(JwtConsumer.java:459) ~[jose4j-0.9.6.jar:?]
	at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:304) ~[jose4j-0.9.6.jar:?]
	at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:410) ~[jose4j-0.9.6.jar:?]
	at org.apache.kafka.common.security.oauthbearer.internals.secured.ValidatorAccessTokenValidator.validate(ValidatorAccessTokenValidator.java:156) ~[kafka-clients-3.7.0.jar:?]
	... 61 more

examing the stack trace I see that OAuthBearerSaslServer.process is going doing the token == null path, which causes a error response to be returned to the caller. The filter isn't treating this an an exception, so the Sasl Auth Request is being fowarded. You see a warn written to Kroxylicious's logs, but the connection between client/broker is still setup.

k-wall · 2024-05-27T15:13:06Z

To work with auth0, I found I need to pass through the SASL_OAUTHBEARER_EXPECTED_AUDIENCE as a config parameter. With that in place, the happy path was good for my test case.

I then tried deliberately poisoning the token presented by the kafka client sasl.oauthbearer.token.endpoint.url=file:////tmp/poisonedtoken

I hit the same problem as above, the Sasl Auth Request is being fowarded despite the duff token.

I have a rough fix which I share with you as a PR (no tests, no docs for the new property).

https://github.com/callaertanthony/kroxylicious/pull/1/files

callaertanthony · 2024-05-27T19:10:26Z

To work with auth0, I found I need to pass through the SASL_OAUTHBEARER_EXPECTED_AUDIENCE as a config parameter. With that in place, the happy path was good for my test case.

I then tried deliberately poisoning the token presented by the kafka client sasl.oauthbearer.token.endpoint.url=file:////tmp/poisonedtoken

I hit the same problem as above, the Sasl Auth Request is being fowarded despite the duff token.

I have a rough fix which I share with you as a PR (no tests, no docs for the new property).

callaertanthony/kroxylicious#1 (files)

thanks @k-wall , I added tests, doc and the issuer property

tombentley

Thanks @callaertanthony, I found a few more minor things worth discussing.

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java

tombentley · 2024-05-27T23:00:52Z

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java

+            return operation.get();
+        }
+        CompletableFuture<A> future = new CompletableFuture<>();
+        executorService.schedule(() -> {


By discarding the returned ScheduledFuture you're basically allowing the client to send very many SaslAuthenticateRequests, each with its own scheduled completion. Other clients are sharing the same event loop (which is what the executorService here actually is), so with enough scheduled events you might get an obserable noisy neighbour effect.

We should probably hold the last scheduled operation's ScheduledFuture in a field. That would allow us to implement a one-scheduler-slot-per-client policy by cancelling the outstanding operation. We'd need to decide what the right thing to do with the two in-flight requests is. I guess respond to the first with some error code, and allow the second to be scheduled.

If we cancel the first request, a response will be sent to the client no ? How this behavior will prevent the client to start new requests ? We can effectively limit the number of scheduled operations to not , but I don't see how this helps to prevent too many requests ?
Maybe we can refuse new requests from client when another one is already scheduled to fast short circuit ?

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java

k-wall · 2024-05-29T11:41:29Z

@callaertanthony I made a couple of suggestions in callaertanthony#2

k-wall

lgtm. @tombentley would you be able to re-review? I think this is good to merge.

callaertanthony · 2024-06-03T14:48:28Z

thank you for your help

tombentley

Thanks @callaertanthony!

sonarqubecloud · 2024-06-05T02:05:12Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
77.7% Coverage on New Code
4.2% Duplication on New Code

See analysis details on SonarCloud

callaertanthony force-pushed the feat/oauth-proxy branch 8 times, most recently from 3c099bf to ae95b4a Compare May 12, 2024 21:50

tombentley reviewed May 13, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch 7 times, most recently from 5b2c6fe to 24f7a35 Compare May 14, 2024 06:39

k-wall reviewed May 14, 2024

View reviewed changes

docs/available-filters/oauthbearer/oauthbearer.adoc Outdated Show resolved Hide resolved

k-wall reviewed May 14, 2024

View reviewed changes

k-wall reviewed May 15, 2024

View reviewed changes

...us-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerFilter.java Outdated Show resolved Hide resolved

k-wall reviewed May 15, 2024

View reviewed changes

...ylicious-oauthbearer/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearer.java Outdated Show resolved Hide resolved

k-wall mentioned this pull request May 15, 2024

Allow FilterFactory implementations to release resources on shutdown #1208

Closed

callaertanthony force-pushed the feat/oauth-proxy branch 5 times, most recently from 9ff79d4 to 2cfe932 Compare May 16, 2024 18:16

tombentley reviewed May 17, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch from 2cfe932 to c3047aa Compare May 21, 2024 15:11

k-wall reviewed May 21, 2024

View reviewed changes

...validation/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidation.java Outdated Show resolved Hide resolved

k-wall reviewed May 26, 2024

View reviewed changes

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java Show resolved Hide resolved

k-wall approved these changes May 26, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch 3 times, most recently from ab80548 to 651f569 Compare May 27, 2024 06:58

k-wall approved these changes May 27, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch from 651f569 to 18192c7 Compare May 27, 2024 10:00

k-wall reviewed May 27, 2024

View reviewed changes

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java Outdated Show resolved Hide resolved

callaertanthony force-pushed the feat/oauth-proxy branch from ad3a3ca to f50f3bd Compare May 27, 2024 21:29

tombentley reviewed May 27, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch from 2aab4f6 to 684af8d Compare May 28, 2024 09:00

k-wall reviewed May 29, 2024

View reviewed changes

...tion/src/main/java/io/kroxylicious/proxy/filter/oauthbearer/OauthBearerValidationFilter.java Outdated Show resolved Hide resolved

callaertanthony force-pushed the feat/oauth-proxy branch from e8bb1b3 to 0a8c7f9 Compare June 3, 2024 08:03

k-wall approved these changes Jun 3, 2024

View reviewed changes

callaertanthony force-pushed the feat/oauth-proxy branch from 0a8c7f9 to e5ed5e2 Compare June 4, 2024 05:59

tombentley approved these changes Jun 5, 2024

View reviewed changes

callaertanthony and others added 6 commits June 5, 2024 02:40

oauthbearer filter

1e01765

rough fix

b8f94f0

add tests, doc, and issuer property

21f0475

fail if not handshake before authenticate

64eff33

fail early if saslServer is unset

970cf7e

fail fast if handshake with a sasl server exists

b1b9845

tombentley force-pushed the feat/oauth-proxy branch from e5ed5e2 to b1b9845 Compare June 5, 2024 01:40

tombentley merged commit 95fe331 into kroxylicious:main Jun 5, 2024
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OauthBearer validation filter #1195

OauthBearer validation filter #1195

callaertanthony commented May 9, 2024 •

edited

Loading

tombentley left a comment

tombentley May 13, 2024

callaertanthony May 13, 2024

k-wall commented May 14, 2024

tombentley left a comment

tombentley May 17, 2024

callaertanthony May 20, 2024

k-wall left a comment •

edited

Loading

k-wall commented May 27, 2024 •

edited

Loading

k-wall commented May 27, 2024 •

edited

Loading

callaertanthony commented May 27, 2024

tombentley left a comment

tombentley May 27, 2024

callaertanthony May 28, 2024

k-wall commented May 29, 2024

k-wall left a comment

callaertanthony commented Jun 3, 2024

tombentley left a comment

sonarqubecloud bot commented Jun 5, 2024

OauthBearer validation filter #1195

OauthBearer validation filter #1195

Conversation

callaertanthony commented May 9, 2024 • edited Loading

Type of change

Description

Additional Context

Checklist

tombentley left a comment

Choose a reason for hiding this comment

tombentley May 13, 2024

Choose a reason for hiding this comment

callaertanthony May 13, 2024

Choose a reason for hiding this comment

k-wall commented May 14, 2024

tombentley left a comment

Choose a reason for hiding this comment

tombentley May 17, 2024

Choose a reason for hiding this comment

callaertanthony May 20, 2024

Choose a reason for hiding this comment

k-wall left a comment • edited Loading

Choose a reason for hiding this comment

k-wall commented May 27, 2024 • edited Loading

k-wall commented May 27, 2024 • edited Loading

callaertanthony commented May 27, 2024

tombentley left a comment

Choose a reason for hiding this comment

tombentley May 27, 2024

Choose a reason for hiding this comment

callaertanthony May 28, 2024

Choose a reason for hiding this comment

k-wall commented May 29, 2024

k-wall left a comment

Choose a reason for hiding this comment

callaertanthony commented Jun 3, 2024

tombentley left a comment

Choose a reason for hiding this comment

sonarqubecloud bot commented Jun 5, 2024

Quality Gate passed

callaertanthony commented May 9, 2024 •

edited

Loading

k-wall left a comment •

edited

Loading

k-wall commented May 27, 2024 •

edited

Loading

k-wall commented May 27, 2024 •

edited

Loading