Skip to content

Add additional context about the authorization request that can be passed to Authorizer#19247

Open
maytasm wants to merge 1 commit intoapache:masterfrom
maytasm:add_auth_context
Open

Add additional context about the authorization request that can be passed to Authorizer#19247
maytasm wants to merge 1 commit intoapache:masterfrom
maytasm:add_auth_context

Conversation

@maytasm
Copy link
Copy Markdown
Contributor

@maytasm maytasm commented Apr 1, 2026

Add additional context about the authorization request that can be passed to Authorizer

Description

Currently, the Authorizer#authorize interface only accepts AuthenticationResult, Resource, and Action, which provides no context about where an authorization request originated. As a result, authorization requests for the same resource from different code paths look identical. For example, an authorization request for a resource initiated by a user query is indistinguishable from one initiated by a SystemSchema request triggered by the UI.

This becomes a problem when analyzing authorization denials. If a user wants to investigate denials for their datasource, those denials are aggregated with denials from SystemSchema/InformationSchema, making it difficult to distinguish genuine unauthorized access attempts from routine internal checks. When a user refreshes the UI, it iterates over all datasources and issues an internal authorization check for each one; this happens in many places, such as the Supervisors tab, Query tab, and others. As a result, metrics emitted by the Authorizer (such as authorization outcomes) become noisy, since denials from internal UI-driven checks are mixed together with denials from actual user queries.

This change adds an optional Map<String, Object> context parameter to Authorizer#authorize. Callers such as InformationSchema and SystemSchema populate this context map with a callerPath key to indicate the source of the authorization request. This context can then be included in the metrics emitted by Authorizer#authorize, allowing users to filter out internal authorization checks from user-initiated ones.

Key changed/added classes in this PR
  • server/src/main/java/org/apache/druid/server/security/Authorizer.java
  • server/src/main/java/org/apache/druid/server/security/AuthorizationUtils.java
  • sql/src/main/java/org/apache/druid/sql/calcite/schema/InformationSchema.java
  • sql/src/main/java/org/apache/druid/sql/calcite/schema/SystemSchema.java

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • a release note entry in the PR description.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added or updated version, license, or notice information in licenses.yaml
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant