Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.1.1, 2.1.2
-
None
-
None
Description
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.
KIP-432 (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238) 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).