You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched in the issues and found nothing similar.
Motivation
Same as this #13951 - but to support the "simpler" JWT auth workflow/client setup.
Solution
Similar to AuthenticationOAuth2 - firstly AuthenticationToken will need to cache the authenticating JWT in a transient volatile field.
This value will also be injected into AuthenticationDataToken - and getCommandData will now return this value - and not lazily generate a new token.
Meanwhile, a scheduled task will be created, similar to #13951 to refresh the cached token.
Respect backwards compatibility.
Alternatives
Complete #13951 - and use it. In some cases though, using the OAuth client is not appropriate. For example, when using Vault as an OIDC - while also providing apps a Vault agent to do the Vault auth - a clientID and secretID are not needed by the app (as again the OIDC/Vault auth is abstracted away)
Anything else?
No response
Are you willing to submit a PR?
I'm willing to submit a PR!
The text was updated successfully, but these errors were encountered:
@lhotari - if u have some time, can u let me know ur thoughts on the feasibility of having this functionality added? The current details are hopefully enough to enable that conversation - and if no immediate/obvious blockers or issues, I can spend some more time identifying all the changes, and continuing conversation on the dev email distribution. Thanks
if u have some time, can u let me know ur thoughts on the feasibility of having this functionality added? The current details are hopefully enough to enable that conversation - and if no immediate/obvious blockers or issues, I can spend some more time identifying all the changes, and continuing conversation on the dev email distribution. Thanks
@damienburke yes, the plan you have presented looks good to me.
For example, when using Vault as an OIDC - while also providing apps a Vault agent to do the Vault auth - a clientID and secretID are not needed by the app (as again the OIDC/Vault auth is abstracted away)
Just curious, how is this configured with the Pulsar client?
Sure. We configure the token supplier method to make the Vault API call. This call is proxied through a Vault Agent - and the Vault Agent handles the auth.
Search before asking
Motivation
Same as this #13951 - but to support the "simpler" JWT auth workflow/client setup.
Solution
Similar to
AuthenticationOAuth2
- firstlyAuthenticationToken
will need to cache the authenticating JWT in atransient volatile
field.This value will also be injected into
AuthenticationDataToken
- andgetCommandData
will now return this value - and not lazily generate a new token.Meanwhile, a scheduled task will be created, similar to #13951 to refresh the cached token.
Respect backwards compatibility.
Alternatives
Complete #13951 - and use it. In some cases though, using the OAuth client is not appropriate. For example, when using Vault as an OIDC - while also providing apps a Vault agent to do the Vault auth - a clientID and secretID are not needed by the app (as again the OIDC/Vault auth is abstracted away)
Anything else?
No response
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: