strimzi-kafka-oauth
strimzi-kafka-oauth copied to clipboard
strimzi
[QUESTION] Password grant type
Hello everybody, your implementation looks really good. Thanks for that. One question: is there a reason why only the client credential flow is implemented and not the password grant type for which you have to get an access or refresh token manually beforehand? regards, Ted
One of the main value propositions of using OAuth is to allow users to keep their passwords private - not leak them to third party servers, not store them into config files ...
For securing Kafka sessions between Kafka clients and brokers, the clients are primarily long running services, not interactive user sessions, and so the most appropriate way is to use client credentials where clients represent themselves. You could create a regular user account for each specific service, but that seems like a 'hackish' approach. Configuring regular users typically requires assigning an email, using a registration flow to validate the email, and handling the account as if there is a real physical person behind it. For 'service' users you typically use 'clients'. If a client secret is leaked you can just disable the client, and the exploitable scope is also limited. If a physical person's password is leaked it can potentially give attacker access to multiple web based systems tied to the same authorization server through their login pages.
Do you have a use case where for some reason you don't want or can't use client credentials for Kafka clients?
In fact, I have a use case: For regulatory reasons, all users must be managed in one place (Active Directory). Technical accounts (machine to machine) have also grown historically in the AD. This means that the credential flow is not possible and only the password flow can be used. Indeed, this may be a special use case ...
Have you tried to configure your authorization server with AD as identity provider? Usually authorization servers allow you to map AD / LDAP users and groups using some query syntax so you can map regular user accounts as separate from service accounts (clients) which you can then use with client_credentials grant.
AFAIK that is the usual route that people take.
On Wed, May 13, 2020, 14:27 Ted [email protected] wrote:
In fact, I have a use case: For regulatory reasons, all users must be managed in one place (Active Directory). Technical accounts (machine to machine) have also grown historically in the AD. This means that the credential flow is not possible and only the password flow can be used. Indeed, this may be a special use case ...
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/strimzi/strimzi-kafka-oauth/issues/56#issuecomment-627948290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUG6A6IFWYCTQHZDUKYALRRKG2JANCNFSM4M5KLO5A .
I am in an corporate environment where the Identity Provider Server is under control of the security team, and they generally disabled the client credential flow by policy. A password credential flow is required, and this is out of my control.
So I would also love to see it supported here, even if it is the "wrong choice" and "hackish". Even though I agree with this assessment, it's simply beyond my control to make the "right" choice, and therefore I can only use OAuth if this library supports my situation.
There is an oauth.refresh.token option which you can use. Rather than having to configure your Kafka client with username and password in clear text, a human configuring the client can perform a UI based login using a web browser or a CLI based login using a password flow (you can do that using curl). You then extract the refresh_token from the token response, and set it as the value of oauth.refresh.token sasl.jaas.config parameter.
Would that not work for you @pantaoran ?