asyncapi/bindings

Custom SASL Mechanisms for Kafka

edeesis opened this issue · 5 comments

edeesis commented

Reason/Context

Please try answering few of those questions

  • Why we need this improvement?

In asyncapi/spec#466, security protocol and sasl mechanisms were added to the security scheme. However, the options provided are not exhaustive, for example with IAM Auth. Nor should they be because anyone can write their own SASL Mechanism.

Ideally there should be some way to set these values to something other than what's included in the spec.

  • How will this change help?

There's no obvious way right now to document non-standard SASL mechanisms.

  • What is the motivation?

Users that utilize custom SASL mechanisms have no way right now to document those authentication strategies.

Description

Please try answering few of those questions

  • What changes have to be introduced?

Instead of only accepting an enum for components.securitySchemes[].type, new properties could be added to securityScheme to override the values.

I do find it a bit confusing how to map the values in security schemes to the Kafka values. This table helps, but it would be nice if this table was made available in the documentation.

  • Will this be a breaking change?

Should be able to be done without a breaking change.

  • How could it be implemented/designed?

Allow more than just enum values for components.securitySchemes[].type, or add a new field to security schemes to allow overriding the mechanism.

github-actions commented

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

dalelane commented

I completely agree in principle.

As a practical matter, have you got a suggestion for how to achieve this? I can think of two possible approaches:

  1. Change the enum to be a string that has documented suggestions for common values, rather than an enumerated list
  2. Add a "custom" option to the existing enum, and an additional optional field to provide details about the custom option

I'm not a JSON schema expert, so there are likely other approaches I'm not thinking of!

edeesis commented

Hi @dalelane. My apologies for the incredibly slow response time. The email for this must've gotten lost in the shuffle.

I think option 2 is probably the cleanest, if for no other reason than to allow the mapping between type and sasl.mechanism to be more explicit.

Adding custom bindings for Kafka on the security scheme object for sasl.mechanism makes the most sense to me.

  • 👍1
github-actions commented

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

edeesis commented

I'm interested in picking this up if no one else is, but I don't currently have the bandwidth to visit it.