Support batch authorization via Authorizer

[gallyamb]

As of now Authorizer supports only one authorization request. It's ok when authorization data is accessed in-memory, but for Authorizers backed by a separate service such design adds unnecessary overhead. It'd be better to check for all grants in one network request, rather than doing multiple smaller requests

I propose adding a new method to Authorizer with a BatchAuthorizationRequest (the rest is omitted for clarity):

public interface Authorizer extends Plugin {
  /** Authorizes an action based on the actor, the resource, and required privileges. */
  default AuthorizationResult authorize(@Nonnull final AuthorizationRequest request) {
    return new AuthorizationResult(request, AuthorizationResult.Type.DENY, "Not Implemented.");
  }

  /**
   * Authorizes an actions based on the actor, the resource, and required privileges
   */
  default BatchAuthorizationResult authorizeBatch(
      @Nonnull final BatchAuthorizationRequest batchRequest) {
    List<AuthorizationResult> results = batchRequest.getIndividualRequests()
        .map(this::authorize)
        .toList();
    return new BatchAuthorizationResult(batchRequest, results);
  }
}

Then com.datahub.authorization.AuthUtil#isAuthorized(com.datahub.authorization.AuthorizationSession, com.datahub.authorization.DisjunctivePrivilegeGroup, com.datahub.authorization.EntitySpec) will take care of calculating the final decision based on the returned results (taking into account disjunctive/conjunctive groups)

Existing Authorizer implementations wouldn't notice any difference, while new ones may take advantage of the batch form

[gallyamb]

AuthorizationContext will also cache the results as now and will only forward requests that haven't been cached. Therefore, there will be no performance issues compared to the current state

[gallyamb]

UPDATED: 2025.12.10

I've implemented batched authorization. And there are some differences compared to the proposal above:

1. the BatchAuthorizationResult contains a Map<String, AuthorizationResult> results field
2. we will provide a default LazyHashMap implementation, that would not actually compute a result at a moment of calling
3. therefore, this way implementations of the Authorizer that do not support batch authorization still would authorize one request at a time, while Authorizers with batch support may do their authorization logic in a one request
4. AuthorizationContext, that is responsible for caching the authorization results for current request, will decorate a result with it's own LazyHashMap, that looks up for a cached value and only after cache miss calls the actual authorization code
5. AuthorizerChain will decorate a result with it's own LazyHashMap, that allows to combine multiple Authorizers' results

AuthorizerChain implementation details

The step by step process in the AuthorizerChain:

1. wrap the results above into the new LazyHashMap and return a new BatchAuthorizationResult
2. when LazyHashMap is actually consumed within AuthUtil, calling the get(privilege) on it returns the merged result:
   1. that call actually causes calling the computation function of the LazyHashMap from AuthorizerChain
   2. it looks in order for the result of each Authorizer's results map
   3. when it finds first ALLOW it eagerly returns ALLOW
   4. when there is no any ALLOW result it returns DENY
3. if the privilege authorization result was not requested, then there wouldn't any call to the results map. So eventually non-batch authorizers would not compute a result for such privileges

The final Authorizer interface

/**
 * An Authorizer is responsible for determining whether an actor should be granted a specific
 * privilege.
 */
public interface Authorizer extends Plugin {
  /** Authorizes an action based on the actor, the resource, and required privilege. */
  default AuthorizationResult authorize(@Nonnull final AuthorizationRequest request) {
    return new AuthorizationResult(request, AuthorizationResult.Type.DENY, "Not Implemented.");
  }

  /** Authorizes an actions based on the actor, the resource, and required privileges. */
  default BatchAuthorizationResult authorizeBatch(
      @Nonnull final BatchAuthorizationRequest batchRequest) {
    return new BatchAuthorizationResult(batchRequest, new LazyHashMap<>(this::authorize));
  }
}

The BatchAuthorizationRequest class

@Value
public class BatchAuthorizationRequest {
  /** The urn of the actor (corpuser) making the request. */
  String actorUrn;

  /** The privileges that the user is requesting */
  Set<String> privileges;

  /**
   * The resource that the user is requesting for, if applicable. If the privilege is a platform
   * privilege this optional will be empty.
   */
  Optional<EntitySpec> resourceSpec;

  /** The sub-resources that are being applied as a modification to the target resource */
  Collection<EntitySpec> subResources;

  public Stream<AuthorizationRequest> getIndividualRequests() {
    return privileges.stream()
        .map(privilege -> new AuthorizationRequest(actorUrn, privilege, resourceSpec, subResources));
  }
}

The BatchAuthorizationResult class

@Value
public class BatchAuthorizationResult {
  /** The original authorization request */
  BatchAuthorizationRequest request;

  /** Results per individual privilege */
  Map<String, AuthorizationResult> results;
}

[gallyamb]

Are DataHub team interested in merging described proposal into the upstream? @yoonhyejin @david-leifker

I can (I believe 😅) prepare an MR for that change