1.1 · Why this is the DBA’s favorite module
The objection every DBA raises: “I already maintain these permissions in Snowflake/Databricks — I am not maintaining a second copy in your tool.” Correct instinct. With per-member authentication, each TextQL member queries the warehouse as themselves — so the policies you already wrote are the policies that run. One connector, no policy translation, no second copy, and your warehouse audit log shows the real human on every query.| Warehouse | Mechanism |
|---|---|
| Snowflake | External OAuth (SSO, no popup), popup OAuth, or token exchange |
| Databricks | OAuth / identity federation (Unity Catalog row filters & column masks apply per user) |
1.2 · Turn it on
Do: on the connector, select Per-Member OAuth and complete the warehouse-side setup (Snowflake: a security integration; Databricks: OAuth app / federation — the Connect Your Data workshop has the field-by-field forms, and the Admin & Governance workshop covers the credential decision). Each member authenticates once — or silently via SSO token exchange.1.3 · Watch your own policies work
As a member with a restricted warehouse role (pick a real one — a regional analyst, a masked-PII role):Prompt
You’ll see: only the rows that member’s warehouse role permits — the same result they’d get in a SQL client — because it IS their identity running the query. Protected columns come back masked if your masking policies say so. Nothing was configured in TextQL to make this happen.
The compliance money moment — Open your warehouse’s audit/query history: the query shows the actual user, their effective role, the executed SQL, and the objects touched. Your existing compliance tooling sees TextQL queries exactly like any other client’s. Show this to your security team before they ask.
1.4 · When per-member auth doesn’t fit
- The warehouse doesn’t support it (some on-prem / SaaS sources) → role-specific restricted credentials: one connector per persona, each with a narrow warehouse role. Never one broad shared credential across personas with materially different entitlements.
- External users without warehouse accounts (embedded, customer-facing) → tenant-bound sessions from a trusted backend + ontology guards (Module 3).
- You need semantics on top anyway — per-member auth enforces access; it doesn’t make “revenue” mean the right thing. Governed definitions still come from the ontology either way.
✅ Checkpoint
- Per-member auth is on for at least one warehouse connector (or you’ve documented why it can’t be)
- A restricted member’s question returned only their permitted rows — verified live
- You found the query in the warehouse’s own audit log under the member’s identity