Child pages
  • KIP-50 - Move Authorizer to o.a.k.common package
Skip to end of metadata
Go to start of metadata


Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]


Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).


Kafka supports pluggable authorization. Third party authorizer implementations allow existing authorization systems like, Apache Sentry, Apache Ranger, etc to extend authorization to Kafka as well. Implementing Kafka's authorizer interface requires depending on kafka's core, which is huge. This has been already raised as a concern by Sentry, Ranger and Kafka community. Even Kafka clients require duplication of authorization related classes, like Resource, Operation, etc, for adding ACLs CRUD APIs.

Kafka authorizer is agnostic of principal types it supports, so are the acls CRUD methods in Authorizer interface. The intent behind is to keep Kafka principal types pluggable, which is really great. However, this leads to Acls CRUD methods not performing any check on validity of acls, as they are not aware of what principal types Authorizer implementation supports. This opens up space for lots of user errors, KAFKA-3097 is an instance.

Public Interfaces

Move Authorizer interfaces and related classes to common module.

Following interface and classes will be moved to

  1. Authorizer
  2. Acl
  3. Operation
  4. PermissionType
  5. Resource
  6. ResourceType
  7. Session

Add method to get authorizer implementation specific description to Authorizer interface.

Add exceptions related to Authorizer.

Following exceptions will be added to org.apache.kafka.common.errors.





Update Authorizer interface to get rid of getter naming convention.



Proposed Changes

The KIP proposes to move authorizer interface and all related classes, i.e., Acl, Operation, PermissionType, Resource, ResourceType, and Session, to a separate package, Third-party authorizer implementations and  core can depend on clients module to access Authorizer interface and related classes. Only change made to default authorizer, SimpleAclAuthorizer, will be the interface it extends.

Authorizer interface will be updated to remove getter naming convention and expected exceptions will be added.

description() will be added to Authorizer interface. Each authorizer implementation can override this method to provide info on implementation specific aspects of authorizer, for instance, Principal Types it supports. The description will be provided by CLI when --help is specified. The KIP suggests that acls should be validated in authorizer implementations.

The changes are backwards incompatible and authorizer implementations will have to be updated to use the new interface and related classes. Apache Ranger and Apache Sentry, only known third party authorizer implementations, are OK with making this backwards incompatible change. 

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
    • Users will have to upgrade third party authorizer implementations along with broker upgrade, else Kafka broker will fail to start.
  • If we are changing behavior how will we phase out the older behavior?
    • This will require a breaking change for third party implementations. Apache Ranger and Apache Sentry, only known third party authorizer implementations, are OK with making this backwards incompatible change.
  • If we need special migration tools, describe them here.
    • None.
  • When will we remove the existing behavior?
    • Existing Authorizer interface and related classes will be removed as part of the changes made as per this KIP.

Rejected Alternatives

  • Add getSupportedPrincipalTypes in authorizer interface.
  • Add validation at Authorizer level.
  • An alternative of providing supported Principal types via interface is via a config option.
  • Add description() method to Authorizer.
  • Create a new module for authorizer, so that third party implementations will not have to depend on clients or core. However, to be consistent with current code org, this is rejected.
  • No labels