Hi, Ron, Thanks for the KIP. +1 from me. Just a few minor comments below.
1. It seems that we can translate an OAuth token to a principle name through the claim name configured in JASS. However, it's not clear to me how an OAuth token is mapped to a claim. Could you clarify that? 2. The wiki has the following code. It seems that OAuthBearerTokenCallback should implement AuthenticateCallbackHandler? Ditto for OAuthBearerValidatorCallback. public class OAuthBearerTokenCallback implements Callback 3. In OAuthBearerTokenCallback, we have the following method. The OAuth spec says the error code is a single ASCII. So, should we return a Char or a String? public String errorCode() Jun On Thu, May 3, 2018 at 8:55 PM, Ron Dagostino <rndg...@gmail.com> wrote: > Hi everyone. I would like to start the vote for KIP-255: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876 > > This KIP proposes to add the following functionality related to > SASL/OAUTHBEARER: > > 1) Allow clients (both brokers when SASL/OAUTHBEARER is the inter-broker > protocol as well as non-broker clients) to flexibly retrieve an access > token from an OAuth 2 authorization server based on the declaration of a > custom login CallbackHandler implementation and have that access token > transparently and automatically transmitted to a broker for authentication. > > 2) Allow brokers to flexibly validate provided access tokens when a client > establishes a connection based on the declaration of a custom SASL Server > CallbackHandler implementation. > > 3) Provide implementations of the above retrieval and validation features > based on an unsecured JSON Web Token that function out-of-the-box with > minimal configuration required (i.e. implementations of the two types of > callback handlers mentioned above will be used by default with no need to > explicitly declare them). > > 4) Allow clients (both brokers when SASL/OAUTHBEARER is the inter-broker > protocol as well as non-broker clients) to transparently retrieve a new > access token in the background before the existing access token expires in > case the client has to open new connections. > > Thanks, > > Ron >
