Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

gt; 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 S

Re: [DISCUSS] KIP-297: Externalizing Secrets for Connect Configurations

Hi Robert. You may find KIP-269: Substitution Within Configuration Values ( https://cwiki.apache.org/confluence/display/KAFKA/KIP+ 269+Substitution+Within+Configuration+Values) to be interesting. I don't know if it is relevant here -- I agree with Magesh, more concrete details would help,

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

HI again, everyone. Still looking for 2 more binding votes. PR is now available at https://github.com/apache/kafka/pull/4994. Ron On Tue, May 8, 2018 at 9:45 AM, Ron Dagostino <rndg...@gmail.com> wrote: > HI everyone. Can we get 2 more binding votes on this KIP (and non-binding >

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

HI everyone. Can we get 2 more binding votes on this KIP (and non-binding votes, too)? Ron On Fri, May 4, 2018 at 11:53 AM, Rajini Sivaram <rajinisiva...@gmail.com> wrote: > Hi Ron, > > +1 (binding) > > Thanks for the KIP! > > Regards, > > Rajini > &

Re: [VOTE] KIP-290: Support for wildcard suffixed ACLs

Hi Piyush. I think it would be better to match the flag in kafka-acls.sh to the new enum. Instead of stating “–wildcard-suffixed-resource true” I think “–resource-type wildcard” is much better because it allows support for new enum constants that might be added in the future via the same

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

w comments: https://github.com/apache/kafka/pull/4994 Ron On Wed, May 16, 2018 at 8:09 PM, Jun Rao <j...@confluent.io> wrote: > Hi, Ron, > > Thanks. I understand now. It may be useful to add a reference to JWT in the > KIP. > > Jun > > On Tue, May 15, 2018 at 6:51 PM,

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

github.com/apache/kafka/pull/4994 and is squashed/rebased onto trunk. Ron On Mon, May 21, 2018 at 8:25 AM, Damian Guy <damian@gmail.com> wrote: > +1 (binding) > > Thanks > > On Mon, 21 May 2018 at 04:59 Ron Dagostino <rndg...@gmail.com> wrote: > > > Hi

Re: [DISCUSS] KIP-297: Externalizing Secrets for Connect Configurations

Hi Robert. Regarding your comment "use the lease duration to schedule a configuration reload in the future", you might be interested in the code that does refresh for OAuth Bearer Tokens in KIP-255; specifically, the class

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

y. I understood your answers to #2 and #3. > > For #1, will the server map all clients' principal name to the value > associated with "sub" claim? How do we support mapping different clients to > different principal names? > > Jun > > On Mon, May 14, 2018 at

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

Hi Committers. One more binding affirmative vote is required if KIP 255 is to have a chance of being included in the 2.0.0 release. Please vote today. Ron > On May 18, 2018, at 9:27 PM, Ron Dagostino <rndg...@gmail.com> wrote: > > Hi committers. KIP 255 still needs 1 mo

Re: [VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

Hi committers. KIP 255 still needs 1 more binding vote. Currently there are two binding + 1 votes, from Rajini and Jun, and three non-binding +1 votes, from Mickael, Manikumar, and myself. Please vote by the Monday deadline. Ron On Thu, May 17, 2018 at 10:59 AM, Ron Dagostino <r

Re: [DISCUSS] KIP-290: Support for wildcard suffixed ACLs

Wed., 2 May 2018, 1:37 am Ted Yu, <yuzhih...@gmail.com> > wrote: > > > > > > > > > > > > > w.r.t. naming, we can keep wildcard and drop 'prefixed' (or > > > > 'suffixed') > > > > > > > since the use of regex would always s

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

proposal reflecting the excellent feedback received to date. I will put this KIP up for a vote in 3 days (no earlier than Thursday evening, EDT) in the absence of feedback that would indicate the need for more discussion. Ron On Thu, Apr 19, 2018 at 11:24 AM, Ron Dagostino <rndg...@gmail.com>

Re: [DISCUSS] KIP-290: Support for wildcard suffixed ACLs

Hi Piyush. I appreciated your talk at Kafka Summit and appreciate the KIP -- thanks. Could you explain these mismatching references? Near the top of the KIP you refer to these proposed new method signatures: def getMatchingAcls(resource: Resource): Set[Acl] def getMatchingAcls(principal:

[VOTE] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

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

Request for Create Page permission in Confluence wiki

Hello, I would like to author a KIP but do not have privileges to create pages in Confluence. Can you add the privilege to my ID (rndgstn)? Ron

[DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

Hi everyone. I created KIP-255: OAuth Authentication via SASL/OAUTHBEARER (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876 ). This KIP proposes adding the ability to authenticate to Kafka with

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

RefreshConfig ? > > Thanks > > On Wed, Feb 14, 2018 at 3:38 PM, Ron Dagostino <rndg...@gmail.com> wrote: > > > Hi everyone. > > > > I created KIP-255: OAuth Authentication via SASL/OAUTHBEARER > > <https://cwiki.apache.org/confluence/pages/viewpage. >

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

blocks are also up-to-date. Ron On Wed, Feb 14, 2018 at 8:11 PM, Ron Dagostino <rndg...@gmail.com> wrote: > Thanks, Ted. I've added the JIRA and mailing list links to the KIP, and I > added Javadoc addressing your questions -- both in the KIP code blocks and > on GitHub (htt

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

. Having > these mechanism-specific objects in a Map doesn't feel ideal. It will > probably be better to define OAuthBearerExtensionsValidatorCallback with a > token getter that returns OAuthBearerToken in that case. > > Thoughts? > > > On Wed, Aug 8, 2018 at 6:09 PM, Ron Dagostino wrote: > > &g

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

en, SaslExtensions ext): We > >don't want token validator to see extensions since these are insecure > > but > > token validation needs to be secure. So we prefer to use a second > > callback > >handler to validate extensions after securely validating token. > &

Re: [DISCUSS] add connect-related packages to "What is considered a "major change" that needs a KIP?"

Yes, I have recently been wondering what exactly the set of public-facing APIs really is. If it is fact defined by the Javadoc then the KIP info page should state this. In case anyone finds it helpful, see below for one (admittedly imperfect) way to see the list of packages. There is probably a

Re: [DISCUSS] add connect-related packages to "What is considered a "major change" that needs a KIP?"

Oops, ignore that messy shell command -- it misses the streams packages. If anyone knows how to use gradle to get the actual list of packages I would be interested in knowing the command. Ron On Wed, Aug 8, 2018 at 9:59 AM Ron Dagostino wrote: > Yes, I have recently been wondering what exac

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

validate > hostname/port is what client expected). Keep in mind that the server > exposes the properties via `getNegotiatedProperty` so it makes sense to > allow the server to have custom validation on the extensions. > > Best, > Stanislav > > On Wed, Aug 8, 2018 at 3:29 PM

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

t; > > > > > > >- New config option for default, unsecured bearer tokens - > > > >`unsecuredLoginExtension_`. > > > > > > > > > > > > 2. Can you add the package for SaslExtensionsCallback class? > >

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

andle > > UnsupportedCallbackException for SaslExtensionsValidatorCallback for > > backwards compatibility, but that should be ok. > > > > What do you think? > > > > > > On Wed, Aug 8, 2018 at 5:06 PM, Stanislav Kozlovski < > > stanis...@confluent

[DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Hi everyone. I created KIP 368: Allow SASL Connections to Periodically Re-Authenticate (

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

dProperty() > > method such that the OAUTHBEARER.token can never be overridden. I > > considered adding a test for that, but I figured having the regex > > validation be enough of a guarantee. > > > > On Thu, Jul 19, 2018 at 9:49 AM Ron Dagostino wrote: > > > >

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

Hi Stanislav. Could you add something to the KIP about the security implications related to the CSV name/value pairs sent in the extension? For example, the OAuth access token may have a digital signature, but the extensions generally will not (unless one of the values is a JWS compact

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

this class, so it is convenient to have an implementation since > users need to create an instance. The class provided by the public API > should be sufficient in the vast majority of the cases. Ron, do you agree? > > On Mon, Jul 23, 2018 at 11:35 AM, Ron Dagostino wrote: >

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

art the [VOTE] thread > tomorrow. > > Best, > Stanislav > > On Tue, Jul 24, 2018 at 6:34 AM Ron Dagostino wrote: > > > Hi Stanislav. Could you update the KIP to reflect the latest definition > of > > SaslExtensions and confirm or correct the impact it has to

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

est approach. The current > ScramExtensions implementation uses a Map in the public credentials and I > thought I would follow convention rather than introduce my own thing, but > maybe this is best > > On Fri, Jul 20, 2018 at 8:39 AM Ron Dagostino wrote: > > > Hi Stanislav

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

rn extensionMap.get(name); >} > >public Set extensionNames() { >return extensionMap.keySet(); >} > } > > > >> On Sat, Jul 21, 2018 at 9:01 PM, Ron Dagostino wrote: >> >> Hi Stanislav and Rajini. If SaslExtensions is going to part of the pu

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

rnally. Thoughts? Ron On Sun, Jul 22, 2018 at 12:45 PM Ron Dagostino wrote: > Hi Rajini. The SaslServer is going to have to validate the extensions, > too, but I’m okay with keeping the validation logic elsewhere as long as it > can be reused in both the client and the secret. > &

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

ions for keys/values you mentioned are in RFC 7628 ( > https://tools.ietf.org/html/rfc7628) ? I could not find any while > originally implementing this. > > Best, > Stanislav > >> On Sun, Jul 22, 2018 at 6:46 PM Ron Dagostino wrote: >> >> Hi again, Rajini and S

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

ould > have > > > both OAuthBearerTokenCallback and SaslExtensionsCallback processed by > a > > > login callback handler. And the map returned by SaslExtensionsCallback > > > could be added to Subject by the default > > OAuthBearerSaslClientCallbackHandler. > &

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

ls/OAuthBearerSaslClient.java#L92 > And yes, in that case you would need a custom `LoginModule` which populates > the Subject in that case, although I'm not sure if Kafka supports pluggable > LoginModules. Does it? > > Best, > Stanislav > > On Wed, Jul 18, 2018 at 9:50 AM Ron Dago

Re: [VOTE] 2.0.0 RC3

+1 (non-binding) Built from source and exercised the new SASL/OAUTHBEARER functionality with unsecured tokens. Thanks, Rajini -- apologies for KAFKA-7182. Ron On Tue, Jul 24, 2018 at 5:10 PM Vahid S Hashemian wrote: > +1 (non-binding) > > Built from source and ran quickstart successfully

Re: [VOTE] KIP-342 - Add support for custom SASL extensions in OAuthBearer authentication

+1 (Non-binding). Thanks for the KIP and the PR, Stanislav. Ron On Wed, Jul 25, 2018 at 1:04 PM Stanislav Kozlovski wrote: > Hey everbody, > > I'd like to start a vote thread for KIP-342 Add support for custom SASL > extensions in OAuthBearer authentication > < >

Re: [DISCUSS] KIP-346 - Limit blast radius of log compaction failure

<< wrote: > On Mon, Jul 23, 2018, at 23:20, James Cheng wrote: > > Hi Stanislav! Thanks for this KIP! > > > > I agree that it would be good if the LogCleaner were more tolerant of > > errors. Currently, as you said, once it dies, it stays dead. > > > > Things are better now than they used to be.

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

to OAuthBearerUnsecuredLoginCallbackHandler in the text in addition to giving the examples? The examples show the new unsecuredLoginExtension_ feature, but that feature is not described anywhere prior to it appearing there. Ron On Mon, Jul 23, 2018 at 1:42 PM Ron Dagostino wrote: > Hi Rajini. I think a class is fine as l

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

<< wrote: > On Wed, Sep 5, 2018, at 07:34, Ron Dagostino wrote: > > I added a "How To Support Re-Authentication for Other SASL Mechanisms" > > section to the KIP as Rajini suggested. I also added a "Rejected > > Alternative" for the idea of forc

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

l? For disconnection as well as > > re-authentication, it will be good if we can specify exactly how it can > be > > implemented for each of the SASL mechanisms, even if we actually > implement > > it only for OAUTHBEARER. > > > > > > On Wed, Sep 5, 2018

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

h you envision bearer tokens changing at? > > Did you consider the alternate solution of terminating connections when > the bearer token changed? > > best, > Colin > > > On Tue, Aug 28, 2018, at 07:28, Ron Dagostino wrote: > > Hi everyone. I created KIP 368: Allo

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

it more involved. Clients may have multiple requests in-flight. > So if we move a channel back to authenticating state when responses are > pending, we may have to cache some responses or propagate responses from > pending requests to the client layer. But it doesn't feel impossibl

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

-- probably not, and I suspect there are unstated assumptions that would be invalidated. Do you think this particular "ConnectionState.REAUTHENTICATING" idea is worth pursuing? How about the general idea of trying to use the TransportLayer directly -- are you still feeling like it is viable

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

work being done in the KafkaChannel instance anyway -- it does some sanity checking but otherwise delegates to the authenticator. We could just add a method to the Authenticator interface and delegate the whole thing. Ron On Wed, Sep 5, 2018 at 2:07 PM Ron Dagostino wrote: > Hi Rajini. I'm

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

at 5:01 PM Ron Dagostino wrote: > Hi again, Rajini, I realized a couple of potential concerns with using > the TransportLayer directly during re-authentication. First, in the > blocking I/O use case, the owner of the NetworkClient instance calls > NetworkClientUtils.sendAndRecei

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ate as anything else (e.g. User:user2) will fail. > > << > >>>if a connection originally authenticates as User:user1, an attempt to > > re-authenticate as anything else (e.g. User:user2) will fail. > > >>>Retry is allowed in this case (still subject to

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

iles#diff-987fef43991384a3ebec5fb55e53b577 > in ControllerChannelManager. Those classes shouldn't have deal with SASL or > reauthentication. Anyway, I will get back with more detail on what I had in > mind since that may not be viable at all. > > > > On Thu, Sep 6, 2018 at 1:44

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

eed to read through to figure that > out, so sub-titles would help). > > Once the KIP is updated, it will be good to get more feedback from the > community to decide on the approach to adopt. > > > On Sat, Sep 8, 2018 at 1:27 PM, Ron Dagostino wrote: > > > Hi yet again, Rajin

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

> The >number of classes modified will be smaller and the number of packages >modified even smaller. > > Anyway, let me know what you think: > >- Will this approach work for your scenarios? >- Do we really need to handle re-authentication differ

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ReplicaFetcherBlockingSend, via ReplicaFetcherThread Is it conceivable that one of these use cases might be more latency-sensitive than others and might desire interleaving? A high-level approach would give us the option of configuring each use case accordingly. Ron On Fri, Sep 7, 2018 at 10:50 PM Ron Dagostino

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

is used 2) We must accept the bigger latency spikes associated with not interleaving requests Does this sound right to you, and if so, do you find these conditions acceptable? Or have I missed something and/or made incorrect assumptions somewhere? Ron On Fri, Sep 7, 2018 at 5:19 PM Ron Dagostino

Add to contributor list

<<

[DISCUSS] KIP-269: Substitution Within Configuration Values

Hi everyone. I created KIP-269: Substitution Within Configuration Values (https://cwiki.apache.org/confluence/display/KAFKA/KIP+ 269+Substitution+Within+Configuration+Values

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

which will be configurable anyway. >8. OAuthBearerTokenRetriever: This could perhaps be a login callback if >we made the login callback handler configurable. > > Regards, > > Rajini > > > On Thu, Feb 22, 2018 at 4:16 AM, Ron Dagostino <rndg...@gmail.com&g

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

ill a > pre-req for OAuth? I was wondering whether we still need the ability to add > new substitutable types or whether it would be sufficient to add the > built-in ones to read from file etc. > > > On Thu, Mar 29, 2018 at 6:48 AM, Ron Dagostino <rndg...@gmail.com> wro

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

lready had a way to do that?) > > > > best, > > Colin > > > > > > On Fri, Apr 13, 2018, at 07:16, Rajini Sivaram wrote: > > > Hi Ron, > > > > > > I think we should be able to process substitutions for both static JAAS > > > configur

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

on the same JAAS use case for now, but these additions/clarifications should help if we want to expand the scope to cluster/producer/consumer configs. Ron On Mon, Apr 9, 2018 at 11:22 AM, Ron Dagostino <rndg...@gmail.com> wrote: > Hi folks. Here is a summary of where I think we stand on

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

on On Sun, Apr 8, 2018 at 8:46 PM, Ron Dagostino <rndg...@gmail.com> wrote: > Hi Rajini. I've also been thinking about how sasl.jaas.config will be > parsed. Something that is implicit in the current proposal needs to be > made explicit if this is to be applied mor

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

asswordVaultUrl from the JAAS config > (which it has access to) and retrieve passwords from a password vault? If > we are going to have extensible substitution anyway, then obviously, we > could use that as an option here too. > > > > On Fri, Apr 6, 2018 at 2:47 PM, Ron Dagostin

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

But > we probably want to make sure namespaces are handled consistently for ` > sasl.jaas.config` and other configs. > > > > On Tue, Apr 10, 2018 at 3:41 AM, Ron Dagostino <rndg...@gmail.com> wrote: > > > Hi folks. I updated KIP 269 to help clarify some of the iss

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

t; > be one way of providing passwords and integrating with other password > > > sources, now that we have configurable login callback handlers. I was > > > wondering whether similar approach could be used for the parameters > that > > > OAuth needed to obtain a

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

variables, constructs a Kafka > > configuration > > > > file and then runs the Kafka broker with that file. This also makes > it > > > > straightforward to set configuration keys in tandem, if that's what > you > > > > want. > > > > > > > > I think

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

rt custom substitution mechanisms for these? Perhaps an > example would help since most of us are not that familiar with the > different OAuth options and you have already thought this through in the > context of OAuth? > > Once we identify what we need for OAuth, we could go ba

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

it is looking good. > > > > I have updated KIP-86 and the associated PR to with a new config > > sasl.login.callback.handler.class that matches what you are using in > this > > KIP. > > > > On Thu, Mar 29, 2018 at 6:27 AM, Ron Dagostino <rndg...@gmail.c

Re: [DISCUSS] KIP-255: OAuth Authentication via SASL/OAUTHBEARER

tores etc. > > For token retriever, I think either approach is fine, since it is tied in > with login anyway and would benefit from login manager cache either way. > > Regards, > > Rajini > > On Sat, Mar 10, 2018 at 4:19 AM, Ron Dagostino <rndg...@gmail.com> wrote: &

Re: [DISCUSS] KIP-269: Substitution Within Configuration Values

Hi everyone. There have been no comments on this KIP, so I intend to put it to a vote next week if there are no comments that might entail changes between now and then. Please take a look in the meantime if you wish. Ron On Thu, Mar 15, 2018 at 2:36 PM, Ron Dagostino <rndg...@gmail.com>

Re: [DISCUSS] Replacing EasyMock with Mockito in Kafka

I have used Mockito and am a big fan -- I had never used EasyMock until recently. The concept of record vs. replay mode in EasyMock really annoyed me -- I'm a fan of the "NO MODES" idea ( https://en.wikipedia.org/wiki/Larry_Tesler), and when I encountered it in EasyMock in the context of Kafka

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

. <<>>if a connection originally authenticates as User:user1, an attempt to re-authenticate as anything else (e.g. User:user2) will fail. >>>Retry is allowed in this case (still subject to the expiration of the original credential as described above) Ron On Mon, Sep 3, 2018 at

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

nd not > introduce additional client-broker statefulness. > > Thanks, > Stanislav > > On Tue, Aug 28, 2018 at 5:28 PM Ron Dagostino wrote: > > > Hi everyone. I created KIP 368: Allow SASL Connections to Periodically > > Re-Authenticate > > <

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

PM, Konstantin Chukhlomin < > chuhlo...@gmail.com> > > wrote: > > > > > +1 (non binding) > > > > > > > On Sep 18, 2018, at 1:18 PM, michael.kamin...@nytimes.com wrote: > > > > > > > > > > > > > > > >

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

gt; > > On Fri, Sep 21, 2018 at 5:26 PM Ron Dagostino wrote: > > > > > Hi Everyone. This KIP requires 1 more binding up-vote to be > considered for > > > the 2.1.0 release; please vote before the Monday deadline. > > > > > > The current vote i

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Still looking for a final +1 binding vote to go with the 9 votes so far (2 binding, 7 non-binding). Ron > On Sep 24, 2018, at 3:53 PM, Ron Dagostino wrote: > > **Please vote** . It's getting late in the day and this KIP still requires 1 > more binding up-vote to be considered f

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

s the name of this metric? Does it measure avg or max? My initial reaction is to measure both: *reauthentication-latency-ms-{avg,max}*. Any thoughts? Ron On Wed, Sep 19, 2018 at 9:08 AM Ron Dagostino wrote: > Thanks, Rajini -- I updated the KIP to fix this. > > Ron > > On Wed, Sep 1

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ually disabled and the > client is expected to use the new version of the request after > inter.broker.protocol.version is set to the current version. So, we will > need to rely on this for deciding whether the NetworkClient should use the > re-authenticate request or not, during upgrade. > &g

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

available at *https://github.com/apache/kafka/pull/5582 <https://github.com/apache/kafka/pull/5582>*, is far along and should be finished in the next day or two. Ron On Mon, Sep 24, 2018 at 9:25 PM Ron Dagostino wrote: > Thanks, Jun. > > <<<100 > I added this lin

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

false, > new ApiVersions, > logContext > ) > > Thanks, > > Jun > > On Mon, Sep 24, 2018 at 6:25 PM, Ron Dagostino wrote: > > > Thanks, Jun. > > > > <<<100 > > I added this line to the KIP to clarify the SSL issue: >

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ry. Perhaps the first one should say `it > may be optionally prefixed with the listener name`? > > On Tue, Sep 18, 2018 at 3:55 PM, Ron Dagostino wrote: > > > HI Rajini. The KIP is updated as summarized below, and I will start a > vote > > immediately. > > > &

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Hi Tyler. This KIP is written such that the sever (broker) specifies a session lifetime to the client, and then the client will re-authenticate at a time consistent with that with whatever credentials it has when the re-authentication kicks off. You could specify a low max session lifetime on

Re: [VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

). Ron On Mon, Sep 24, 2018 at 9:47 AM Ron Dagostino wrote: > Hi Everyone. This KIP still requires 1 more binding up-vote to be > considered for the 2.1.0 release. **Please vote before today's end-of-day > deadline.** > > The current vote is 2 binding +1 votes (Rajini and Harsha) and

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

gt; > > 4) The interleaving of requests sounds like a great feature to have, but > > the tradeoff against code complexity is a tough one. I would personally > go > > with the simpler approach since you could always add interleaving on top > if > > the community decides th

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

are ControllerChannelManager and ReplicaFetcherBlockingSend (via ReplicaFetcherThread), and they require a little bit more -- but not much. Thoughts? Ron On Wed, Sep 12, 2018 at 1:57 PM Ron Dagostino wrote: > Thanks, Rajini. Before I digest/respond to that, here's an update that I > just completed. > > I ad

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

good to get the perspective > of others in the community :-) > > On Wed, Sep 12, 2018 at 7:47 PM, Ron Dagostino wrote: > > > Hi Rajini. Here is some feedback/some things I thought of. > > > > First, I just realized that from a timing perspective that I am not sure

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ven't figured out exactly what is needed, but > will think about it and get back next week. In the meantime, you can get > the KIP up-to-date with the config, migration path etc. and get it ready to > start vote next week. > > > > > > On Fri, Sep 14, 2018 at 1:24 PM, Ro

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Minor correction: I'm proposing "connections.max.reauth.ms" as the broker-side configuration property, not " connections.max.expired.credentials.ms". Ron On Fri, Sep 14, 2018 at 8:40 PM Ron Dagostino wrote: > Hi Rajini. I'm going to choose *connections.max.expired

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

e of which may not have been discussed either (and names are missing from some of them). Regardless, this new version is the closest yet to a version that can be put to a vote next week. Ron On Fri, Sep 14, 2018 at 8:59 PM Ron Dagostino wrote: > Minor correction: I'm proposing "connect

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

17, 2018 at 9:13 AM Ron Dagostino wrote: > Hi Rajini. I've updated the KIP to reflect the decision to fully support > this for all SASL mechanisms and to not require the ExpiringCredential > interface to be public. > > Ron > > On Mon, Sep 17, 2018 at 6:55 AM Ron Dagostino wr

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Long value there if there is a lifetime. That well-klnown key (e.g. "Credential.Lifetime") would be part of the public API, right? Ron On Mon, Sep 17, 2018 at 11:03 AM Ron Dagostino wrote: > Hi again, Rajini. After thinking about this a little while, it occurs to > me that mayb

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

io for PLAIN to force > re-authenication at regular intervals. A/B/C are useful to force > re-authentication in scenarios where you might check for credential > revocation in the server. And E/F are useful to disable re-authentication > and generate metrics (also the default behaviour

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

tion-total. I've eliminated that from the KIP for now. Thoughts? There is also a client-side metric for re-authentication latency tracking (still unnamed -- do you have a preference?) I think we're close to being able to put this KIP up for a vote. Ron On Mon, Sep 17, 2018 at 2:45 PM Ron

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

the prefix in the KIP for now, but it would be easier to just set it once for all mechanisms, and I don't see that as being a problem. Let me know what you think. Ron On Mon, Sep 17, 2018 at 9:51 PM Ron Dagostino wrote: > Hi Rajini. The KIP is updated. Aside from a once-over to make sure it is >

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

or a way of extending the mechanism. > > Thoughts? > > On Thu, Sep 13, 2018 at 6:56 PM, Ron Dagostino wrote: > > > Hi Rajini. I'm thinking about how we deal with migration. For example, > > let's say we have an existing 2.0.0 cluster using SASL/OAUTHBEARER and we >

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

> path as client failing to re-authenticte on time). > > Thoughts? > >> On Sat, Sep 15, 2018 at 3:06 AM, Ron Dagostino wrote: >> >> Hi everyone. I've updated the KIP to reflect all discussion to date, >> including the decision to go with the low-level approac

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

next re-authentication on the client >> based on the expiry time provided by the server (some time earlier than the >> expiry). >> 4) If client uses SASL_AUTHENTICATE v0, broker will not return expiry time. >> The connection will be terminated if that feature is enabled (the same co

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Hi Rajini. I've updated the KIP to reflect the decision to fully support this for all SASL mechanisms and to not require the ExpiringCredential interface to be public. Ron On Mon, Sep 17, 2018 at 6:55 AM Ron Dagostino wrote: > Actually, I think the metric remains the same assum

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

that for a separate JIRA (it doesn't need to be implemented at > the same time). > > > > On Tue, Sep 18, 2018 at 3:06 AM, Ron Dagostino wrote: > > > HI again, Rajini. Would we ever want the max session time to be > different > > across different SASL mechanis

[VOTE] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

Hi everyone. I would like to start the vote for KIP-368: https://cwiki.apache.org/confluence/display/KAFKA/KIP-368%3A+Allow+SASL+Connections+to+Periodically+Re-Authenticate This KIP proposes adding the ability for SASL clients (and brokers when a SASL mechanism is the inter-broker protocol) to

Re: [DISCUSS] KIP 368: Allow SASL Connections to Periodically Re-Authenticate

ill feature on each broker via a restart at whatever pace is desired. Comments? Ron On Wed, Sep 12, 2018 at 4:48 PM Ron Dagostino wrote: > Ok, I am tempted to just say we go with the low-level approach since it is > the quickest and seems to meet the clear requirements. We can alway

  1   2   3   >