Hey Ron, thanks for the KIP. I believe the proposed configuration setting `yes.virginia.i.really.do.want.to.allow.unsecured.oauthbearer.tokens.because.this.is.not.a.production.cluster` might be too verbose. I acknowledge that we do not want to enable this in production but we could maybe compromise on a more normal name.
I am wondering whether it would be more worth it to replace the default implementation with a secure one. Disabling it by default can be seen as just kicking the can down the road Best, Stanislav On Wed, Feb 20, 2019 at 5:31 PM Ron Dagostino <rndg...@gmail.com> wrote: > Hi everyone. I created KIP-432: Additional Broker-Side Opt-In for Default, > Unsecure SASL/OAUTHBEARER Implementation > < > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238 > > > ( > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238 > ). > The motivation for this KIPis as follows: > > The default implementation of SASL/OAUTHBEARER, as per KIP-255 > <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876 > >, > is unsecured. This is useful for development and testing purposes, and it > provides a great out-of-the-box experience, but it must not be used in > production because it allows the client to authenticate with any principal > name it wishes. To enable the default unsecured SASL/OAUTHBEARER > implementation on the broker side simply requires the addition of > OAUTHBEARER to the sasl.enabled.mechanisms configuration value (for > example: > sasl.enabled.mechanisms=GSSAPI,OAUTHBEARER instead of simply > sasl.enabled.mechanisms=GSSAPI). To secure the implementation requires the > explicit setting of the > > listener.name.{sasl_plaintext|sasl_ssl}.oauthbearer.sasl.{login,server}.callback.handler.class > properties on the broker. The question then arises: what if someone > either accidentally or maliciously appended OAUTHBEARER to the > sasl.enabled.mechanisms configuration value? Doing so would enable the > unsecured implementation on the broker, and clients could then authenticate > with any principal name they desired. > > This KIP proposes to add an additional opt-in configuration property on the > broker side for the default, unsecured SASL/OAUTHBEARER implementation such > that simply adding OAUTHBEARER to the sasl.enabled.mechanisms configuration > value would be insufficient to enable the feature. This additional opt-in > broker configuration property would have to be explicitly set to true > before the default unsecured implementation would successfully authenticate > users, and the name of this configuration property would explicitly > indicate that the feature is not secure and must not be used in > production. Adding this explicit opt-in is a breaking change; existing > uses of the unsecured implementation would have to update their > configuration to include this explicit opt-in property before their cluster > would accept unsecure tokens again. Note that this would only result in a > breaking change in production if the unsecured feature is either > accidentally or maliciously enabled there; it is assumed that 1) this will > probably not happen to anyone; and 2) if it does happen to someone it > almost certainly would not impact sanctioned clients but would instead > impact malicious clients only (if there were any). > > > Ron > -- Best, Stanislav
