/
Synapse Query Authorization Model

Synapse Query Authorization Model

The authorization model used to determine the query results that a user can see at runtime depends on the type of data being queried. The actual business logic used for any query can be found here: TableQueryManagerImpl.queryPreflight().

Terms

  • Data Source - A table or view.

  • Benefactor - The ID of the ACL that controls access to an Entity. The benefactor is found by walking the Entity hierarchy, starting with the entity itself, and locating the first ACL found in the walk. The ACL might be on the Entity, its parent, grandparent, etc. Benefactors are captured in a view's “index” at view build time. Entity benefactor changes are propagated to the view’s index in near-real-time.

  • Accessible Benefactors - A query-time set of steps used to build a row-level filter that can be applied to a view:

    • Distinct Benefactors - The distinct benefactors are fetched from the view with a single query. This query results in a distinct set of benefactor IDs.

    • Accessible Benefactor sub-set - The following method getAccessibleBenefactors() is used to get the sub-set of benefactors that the user is currently authorized to access.

  • Row-Level Filter - A filter that is automatically added to a user’s query against any type of view. Specifically, the user’s query is modified with: benefactor_i in (:accessibleBenefactors) for each benefactor column of the view.

  • Benefactor Column - Each data source will have zero or more benefactor columns depending on the data source type:

    • Tables - Have no benefactor columns.

    • EntityView - Will always have exactly one benefactor column.

    • MaterializedView - The number of benefactor columns depends on the MV’s defining SQL. For example, an MV that joins two views will have two benefactor columns (one for each view). When an MV includes a join to another MV, the outer MV will include a benefactor column for each inner MV benefactor column. In this way, MV benefactor columns are “recursive”.

    • VirtualTable - Is not an actual data source. Instead, a VT is a virtualization of a query result against an actual data source. The authorization against the actual data source is automatically applied.

Data source authorization Steps:

  1. First, an authorization check is made to determine if the user has the appropriate access to the table/view itself. For all types of views, this is a check of the view’s READ permission. For all tables, this is a check for both READ and DOWNLOAD of the table.

  2. The accessible benefactors are calculated for each benefactor column of the data source. A row-level filter is then applied to the user’s query for each benefactor column.