Hi Rajini, I think Gwen's question was in relation to the fact that we are changing the SASL protocol in KIP-43, not the fact that clients need to know the mechanisms supported by the broker.
I think the approach of returning the supported protocols in the error response works fine. Ismael On 4 Apr 2016 21:31, "Rajini Sivaram" <rajinisiva...@googlemail.com> wrote: > If a client provides a mechanism that is not enabled (or supported) in the > broker, the server rejects the mechanism and returns the set of enabled > mechanisms in the error response. I thought Gwen's question was asking how > a client would be able to determine what mechanisms are supported in the > broker, when support for new mechanisms are added. A version indicator > wouldn't really tell you what mechanisms are actually enabled in the > broker. You either need a failed SASL handshake as you do now, or we could > have server send the list to the client prior to the client choosing its > mechanism. I don't know if there a requirement for clients to query > mechanisms from the broker, but if there was, it would be better to do so > prior to SASL handshake rather than after. > > On Mon, Apr 4, 2016 at 9:08 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Rajini, it's a good point that not all mechanisms may be enabled. > However, > > we can handle that case by rejecting a mechanism requested by the client > > without having to initially provide a list of mechanisms right? > > > > Ismael > > > > On Mon, Apr 4, 2016 at 8:57 PM, Rajini Sivaram < > > rajinisiva...@googlemail.com > > > wrote: > > > > > SASL mechanisms are configurable properties and slightly different from > > > versions since the fact that a broker version *can* support a mechanism > > > doesn't actually mean that a broker *does* support that mechanism. SASL > > > implementations typically interact with external authentication > servers, > > so > > > I would expect many Kafka brokers to enable a only subset of mechanisms > > > supported in a particular broker version. We don't enable Kerberos > > because > > > we don't have a Kerberos authentication server. > > > > > > KIP-43 originally contained a mechanism negotiation phase where the > > broker > > > sent the list of supported mechanisms to the client before SASL > handshake > > > to enable client to choose an enabled mechanism. This was removed after > > > feedback from the community as being unnecessary. Wouldn't it be better > > to > > > reinstate that part of the handshake if we want clients to be able to > > > determine mechanisms enabled in the broker? It may be better than a > > version > > > indicator in the Kafka protocol that cannot be obtained until the > > handshake > > > completes. > > > > > > > > > > > > On Mon, Apr 4, 2016 at 8:41 PM, Magnus Edenhill <mag...@edenhill.se> > > > wrote: > > > > > > > As Jun says the SASL (and SSL) handshake is not done using the Kafka > > > > protocol > > > > and is performed before any Kafka protocol requests pass between > client > > > and > > > > server. > > > > > > > > It might make sense to move the SASL handshake from its custom > protocol > > > > format > > > > into the Kafka protocol and make it use the proper Kafka protocol > > > framing. > > > > > > > > (For SSL this is isnt needed since TLS has its own _standardised_ > > > > hand-shake format and existing SSL implementations take care of it.) > > > > > > > > 2016-04-04 21:20 GMT+02:00 Ismael Juma <ism...@juma.me.uk>: > > > > > > > > > An option would be to add a version for the handshake in the KIP-35 > > > > > response. > > > > > > > > > > Ismael > > > > > On 4 Apr 2016 20:09, "Gwen Shapira" <g...@confluent.io> wrote: > > > > > > > > > > > I think the challenge here is that even after KIP-35 clients will > > not > > > > > know > > > > > > whether the server supports new sasl mechanisms or not, so > non-Java > > > > > clients > > > > > > will have to assume it is not supported (and will therefore lag > > > behind > > > > on > > > > > > features). > > > > > > > > > > > > I think this highlights a short-coming of KIP-35, and I'm > wondering > > > if > > > > > > there are good ways to address this. > > > > > > > > > > > > Gwen > > > > > > > > > > > > > > > > > > On Mon, Apr 4, 2016 at 12:05 PM, Jun Rao <j...@confluent.io> > wrote: > > > > > > > > > > > > > I think with KIP-43, the existing way of sasl handshake during > > > > > connection > > > > > > > still works. It's just that if you want to support non-GSSAPI, > > you > > > > will > > > > > > > need a new sasl handshake implementation in the client. It's > > > > > unfortunate > > > > > > > that Protocol currently only covers the communication after the > > > > > > connection > > > > > > > is ready to use, but not during handshake. For now, we can > > probably > > > > > just > > > > > > > document this change during handshake since changing the > > > > implementation > > > > > > is > > > > > > > optional. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > On Mon, Apr 4, 2016 at 11:28 AM, Gwen Shapira < > g...@confluent.io > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Kafka Team, > > > > > > > > > > > > > > > > As a practical test-case of KIP-35, I'd like to turn your > > > attention > > > > > to > > > > > > > > KIP-43: > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-43 > > > > > > > > > > > > > > > > KIP-43 makes an interesting modification to the protocol, but > > > only > > > > > > under > > > > > > > > specific conditions: > > > > > > > > > > > > > > > > "*Client flow:* > > > > > > > > > > > > > > > > 1. If sasl.mechanism is not GSSAPI, send a packet with the > > > > > mechanism > > > > > > > > name to the server. Otherwise go to Step 3. > > > > > > > > - Packet Format: | Version (Int16) | Mechanism > (String) | > > > > > > > > 2. Wait for response from the server. If the error code in > > the > > > > > > > response > > > > > > > > is non-zero, indicating failure, report the error and fail > > > > > > > > authentication. > > > > > > > > 3. Perform SASL authentication with the configured client > > > > > mechanism > > > > > > > > > > > > > > > > *Server flow:* > > > > > > > > > > > > > > > > 1. Wait for first authentication packet from client > > > > > > > > 2. If this packet is a not valid mechanism request, go to > > > Step 4 > > > > > and > > > > > > > > process this packet as the first GSSAPI client token > > > > > > > > 3. If the client mechanism received in Step 2 is enabled > in > > > the > > > > > > > broker, > > > > > > > > send a response with error code zero and start > > authentication > > > > > using > > > > > > > the > > > > > > > > specified mechanism. Otherwise, send an error response > > > including > > > > > the > > > > > > > > list > > > > > > > > of enabled mechanisms and fail authentication. > > > > > > > > - Packet Format: | ErrorCode (Int16) | EnabledMechanisms > > > > > > > > (ArrayOf(String)) > > > > > > > > | > > > > > > > > 4. Perform SASL authentication with the selected > mechanism. > > If > > > > > > > mechanism > > > > > > > > exchange was skipped, process the initial packet that was > > > > received > > > > > > > from > > > > > > > > the > > > > > > > > client first." > > > > > > > > > > > > > > > > > > > > > > > > I'd love to know how this will be communicated to clients via > > > > > > > > VersionRequest proposed in KIP-35 (mostly because Jun and I > > need > > > to > > > > > > > review > > > > > > > > KIP-43 and we want to be sure we are not breaking the new > > > protocol > > > > at > > > > > > the > > > > > > > > same time we introduce it) > > > > > > > > > > > > > > > > Do we: > > > > > > > > 1. Bump protocol version of every single Request? Even though > > > > unless > > > > > > you > > > > > > > > are using a new sasl mechanism nothing changes? > > > > > > > > 2. Ignore and not bump protocol? If so, how will clients know > > > that > > > > > new > > > > > > > > sasl.mechanisms are supported? > > > > > > > > 3. Something else? > > > > > > > > > > > > > > > > Gwen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > > > > Rajini > > > > > > > > > -- > Regards, > > Rajini >
