Use case

When data entitlements are encoded into CH using grants, roles, and row policies, it is sometimes infeasible to reimplement the same logic in a web service that serves that data to users within the organization. CH should be the source of truth for data access. For instance, consider sales business intelligence app built on top of CH. If certain sales people are each entitled to see only certain subsets of data, it is easier to encode their privileges in CH and rely on the database to enforce those roles rather than encoding them in the application. This is especially true if the organization develops several such "data" applications.

Describe the solution you'd like

1. User ekpdt makes an authenticated request to a web service that provides real time analytics
2. The web service, under its service user webapp, runs a SELECT query against a table, view, or materialized view to satisfy ekpdt's request.
3. Service user webapp has the IMPERSONATE privilege and tags its SELECT statement with SETTINGS impersonate='ekpdt'
4. CH evaluates the query by applying the row policies and grants applicable to ekpdt

Describe alternatives you've considered

The remote() table function is an option, but this forces the web service to know the end user's password. remote() also does not use a connection pool.

Additional context

There was a similar request here at #9751 to support proper row policies and usage accounts for distributed queries.