Add row-level security filter in query

[cecemei]

This PR adds the ability to attach row filters to a query, thus restrict row-level data access for given users.

Description

A query follows these steps: initialize -> authorize -> execute. In the authorize step, the permissions are checked for all the required resources in the query. Before this PR, the authorize step only returns allow or deny access on a table. Granting access to a table means a user can see all data in this table. After this PR, the authorize step can return allow access along with restrictions (i.e. a row filter that must be applied to the table ), which restrict users' data access at row level. For example, customers can only see rows relevant to their company.

The authorizeAllResourceActions now returns a AuthorizationResult instead of Access, this class also replaces DruidPlanner.AuthResult class. The main difference between AuthorizationResult and Access is that the former contains a map of table with DimFilter. It can also have ResourceAction Iterables which DruidPlanner cares about.

In the authorize step of QueryLifecycle, it would enforce the filters on tables in the datasource tree, transform TableDataSource to RestrictedDataSource. In the execute step, filters are applied through RestrictedSegment and RestrictedCursorFactory.

Key changed/added classes in this PR

• a new class AuthorizationResult. The class should be used for all the authorization calls, while the Access class is still used in Authorizer interface. It has an static variable ALLOW_ALL, which should be used for all internal calls. Objects.requireNonNull(authResult.getFailureMessage())) is called to get a failure message, which replaced access.toString(), access.toMessage(), access.getMessage(). The class contains:
  • deny/ allow results for checking permissions on a list of resource actions.
  • failure message if authorization fails, this is null when auth is allowed, and is the error message of the first resource action authorization failure (there might be more failures, but we don't try further)
  • a map of table name with row-level policy filters.
• Access. Added Optional<DimFilter> rowFilter field, which represents a restrictions returned from authorizer. Also updated constructor.
• AbstractStatement. Replace DruidPlanner.AuthResult with AuthorizationResult.
• AuthConfig. Added flag enableStrictPolicyCheck, when enabled, it would check every table needs to have a restriction in place, meaning it has an entry in the restrictions map, could be Optional.empty().
• AuthorizationUtils. It now consolidates all restrictions for authorizing resource actions into a restrictions map, which is included in AuthorizationResult. Also updated javadoc for all public methods.
• a new class RestrictedDataSource, which wraps a TableDataSource with a DimFilter. If the filter is null, meaning there's no applied.
• a new class RestrictedSegment, which represents a segment with a filter.
• a new class RestrictedCursorFactory, can be created by RestrictedSegment.asCursorFactory, enforces the DimFilter on Cursor.
• DataSource interface, added a sub type of restrict, added a default method mapWithRestriction.
• TableDataSource, added the impl of mapWithRestriction.
• JoinDataSource can accept RestrictedDataSource as left-hand side datasource.
• Query interfaced, added a default method withPolicyRestrictions.
• SegmentMetadataQuery, added the impl of withDataSource.
• QueryLifeCycle, replace baseQuery with baseQuery.withPolicyRestrictions if authorization result is not ALLOW_ALL (calls from internal services).

Caveats

• The restrictions don't apply to VIEWs.
• UnionDataSource doesn't work with RestrictedDataSource, planning to fix that later.

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• [] 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.