MINOR: Add authorizer.class.name to the security section in documentation
</ol>
<h3><a id="security_authz" href="#security_authz">7.4 Authorization and ACLs</a></h3>
- Kafka ships with a pluggable Authorizer and an out-of-box authorizer implementation that uses zookeeper to store all the acls. Kafka acls are defined in the general format of "Principal P is [Allowed/Denied] Operation O From Host H On Resource R". You can read more about the acl structure on KIP-11. In order to add, remove or list acls you can use the Kafka authorizer CLI. By default, if a Resource R has no associated acls, no one other than super users is allowed to access R. If you want to change that behavior, you can include the following in server.properties.
+ Kafka ships with a pluggable Authorizer and an out-of-box authorizer implementation that uses zookeeper to store all the acls. The Authorizer is configured by setting <code>authorizer.class.name</code> in server.properties. To enable the out of the box implementation use:
+ <pre>authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer</pre>
+ Kafka acls are defined in the general format of "Principal P is [Allowed/Denied] Operation O From Host H On Resource R". You can read more about the acl structure on KIP-11. In order to add, remove or list acls you can use the Kafka authorizer CLI. By default, if a Resource R has no associated acls, no one other than super users is allowed to access R. If you want to change that behavior, you can include the following in server.properties.
<pre>allow.everyone.if.no.acl.found=true</pre>
One can also add super users in server.properties like the following (note that the delimiter is semicolon since SSL user names may contain comma).
<pre>super.users=User:Bob;User:Alice</pre>
