Token Exchange and Data Access
This page covers how a user's identity flows from the Cogrion UI all the way to a query executing against data — and how access policies are enforced at each step.
The Token Exchange Flow
When a user makes a request through the Cogrion UI to a backend service (Superset, Airflow, JupyterHub), the request passes through the BFF API. The BFF does not forward the user's original token to the backend. Instead, it exchanges it:
- The Cogrion UI sends the request with the user's Keycloak access token.
- The BFF validates the token against Keycloak.
- The BFF requests a new token from Keycloak scoped specifically to the target service (e.g. the Superset client).
- The BFF forwards the request to the backend with the exchanged token.
- The backend service validates the exchanged token and processes the request.
Each backend service only ever receives a token scoped to itself — it never sees the user's original session token.
How Ranger Enforces Data Access
For SQL queries (SQL Lab, Dashboard, Catalog), access policies are enforced by Ranger at the query execution layer:
- The user submits a query through the Cogrion UI.
- The BFF exchanges the token and forwards the request to Superset.
- Superset dispatches the query to Trino.
- Trino checks the user's identity against Ranger policies before executing.
- Ranger applies row-level and column-level restrictions. Restricted rows and columns are excluded from results transparently.
- Trino returns only the data the user is permitted to see.
Access Policy Scope
| Policy Type | What It Controls |
|---|---|
| Database / Schema | Which databases and schemas a user or role can access |
| Table | Which tables within a schema are accessible |
| Column masking | Mask or redact specific columns for specific roles |
| Row filter | Restrict which rows are returned based on user attributes |