Skip to content

Announcing 0.24.0 - #280

Open
SamBarker wants to merge 1 commit into
kroxylicious:mainfrom
SamBarker:feat/blog-0.24
Open

Announcing 0.24.0#280
SamBarker wants to merge 1 commit into
kroxylicious:mainfrom
SamBarker:feat/blog-0.24

Conversation

@SamBarker

Copy link
Copy Markdown
Member

No description provided.

Signed-off-by: Sam Barker <sam@quadrocket.co.uk>
@SamBarker
SamBarker requested a review from a team as a code owner September 2, 2026 09:36

**Why SASL Termination?**

Filters that rely on client identity—such as custom authorization or dynamic routing—need to know *who* is making a request. However, challenge-response mechanisms like SCRAM generate unique per-server nonces, making passthrough inspection impossible.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is incorrect, and describes the wrong thing.

Firstly, SASL Inspection does support SCRAM. The identity goes through the SCRAM mechanism in plain text, so SaslInspection can (and does) sniff it. io.kroxylicious.it.SaslInspectionIT#shouldAuthenticateWhenSameMechanism_SCRAM_SHA_256 proves it works.

Secondly, the need for SASL Termination is really routers with multiple upstreams. In this use case, SASL inspection doesn't really work:

  1. For SASL PLAIN/OAUTH, it works providing the password db or oauth configs are the same.
  2. For SCRAM, it falls flat on its face. There would be two server nonces.

There are use-cases for SASL Termination in a single upstream use-cases - where your client side SASL authn requirements differ from your server side's authn requirements. Say interfaces clients that use SASL with a Cluster that can only use TLS client auth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants