Content for OAuth2/OIDC support for Kafka REST proxy #2237
Conversation
Deploying with
|
| Latest commit: |
3b4276a
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://1f454e93.devportal.pages.dev |
| Branch Preview URL: | https://harshini-oauth-oidc-rest-pro.devportal.pages.dev |
| Authorization enforcement | ||
| ---------------------------- | ||
|
|
||
| The underlying Aiven for Apache Kafka® service uses the ``sub`` claim from the JWT as the username, checking it against configured Access Control Lists (ACLs) to authorize operations on Kafka resources. |
There was a problem hiding this comment.
A small thing here, the default is indeed the sub claim, however on the Kafka side this is configurable via kafka.sasl_oauthbearer_sub_claim_name, as also mentioned in https://docs.aiven.io/docs/products/kafka/howto/enable-oidc#enable-oauth2-oidc-via-aiven-console
There was a problem hiding this comment.
And currently the service user matching the value in the claim is needed, just the ACL entry is not enough.
There was a problem hiding this comment.
Thanks both for your feedback. I have made some changes to the text and would appreciate it if you could review it again.
There was a problem hiding this comment.
Looks good to me!
@jjaakola-aiven could you also check again?
harshini-rangaswamy
force-pushed
the
harshini-oauth-oidc-rest-proxy
branch
from
c6d4b02 to
ed69c14
Compare
harshini-rangaswamy
force-pushed
the
harshini-oauth-oidc-rest-proxy
branch
from
ed69c14 to
231c420
Compare
|
|
||
| While the ``sub`` claim is the default identifier, this setting is configurable. You can specify a different JWT claim for authentication by adjusting the ``kafka.sasl_oauthbearer_sub_claim_name`` parameter. For more information on configuring this, see :ref:`console-authentication`. | ||
|
|
||
| To authenticate and authorize a user in Aiven for Apache Kafka, the JWT claim value and corresponding service user must be explicitly present in the ACL. This means that the identity of the user making the request with the JWT claim value must match the service user in the system. |
There was a problem hiding this comment.
I tried to think how to change the text to be more specific that both are needed. Now I feel that this paragraph mixes/is not exact enough with the difference.
- a matching ACL entry
- a matching service user
For example this would work.
- Service user with username
userid-example. - ACL entry
- username
userid-ex* - topic
example-topic - permission
read|write|readwrite|admin
- username
If service user would be removed from the Aiven for Kafka the authorization would start to fail. This is a bit counter intuitive as ACL should be the only item to affect authorization with OAuth2/OIDC but our system currently links the service users and ACL entries. There is a ticket to remove this link: https://aiven.atlassian.net/browse/HH-2792
So maybe something like this would be better:
To authenticate and authorize a user in Aiven for Apache Kafka a service user and ACL entry describing the permissions is needed. This means that the identity of the user making the request with the JWT claim value must match the service user in the system and must match the ACL entry.
There was a problem hiding this comment.
@jjaakola-aiven I've made the following text updates. Could you check them and confirm if they're alright?
To authenticate and authorize a user in Aiven for Apache Kafka, both a service user and an ACL entry describing the permissions are required. The JWT claim value used for authentication must explicitly match the service user in the system. Furthermore, this service user must be associated with an ACL entry that outlines their permissions, ensuring that the identity of the user making the request aligns with both the service user and the ACL entry.
What changed, and why it matters
Added content for OAuth2/OIDC support for Kafka REST proxy - DOC-592
Note: I will remove the Enable Apache Kafka® REST proxy authorization topic, as I have included this content within this new topic "Enable OAuth2/OIDC support for Apache Kafka® REST proxy".