Permission model at a glance — Role · Collection · FGAC
Align D.Hub's three permission layers (Role · collection ceiling · FGAC) on one screen, and nail down the first rule — *permission grants always start from a collection*.
The admin's first answer is who can see what. D.Hub's permission model unfolds across three layers — this lesson aligns those three layers on one screen and locks down the first rule: permission grants always start from a collection.
Three-layer permission model
| Layer | Granted on | Answers |
|---|---|---|
| Role | Collection / user or group | "Can they access the resource at all?" |
| Collection ceiling | The collection itself | "What's the inheritance cap for sub-assets?" |
| FGAC (Fine-Grained Access Control) | Columns · rows of a dataset | "What data can they see?" |
The three layers stack on top of each other. Role controls access itself, Ceiling sets the cap above, and FGAC narrows what's visible within the same resource.
Layer 1: The three roles
D.Hub's Role taxonomy is just three.
- Reader — Can view resources. Dataset previews, dashboard views, pipeline result checks.
- Writer (Editor) — Can create and modify. Register datasets, build pipelines, edit dashboards.
- Owner — Can grant permissions and delete. Assign roles to other users, delete the collection.
Roles are granted at the collection level. There's no narrower permission like Reader on a single dataset — if you need resource-level granularity, create a separate collection holding just that resource.
Layer 2: Collection ceiling
This is the quirk of D.Hub's model. A role granted on a collection acts as the ceiling for every asset inside it.
Concretely:
- If user A has Reader on collection X, A cannot have higher than Reader on any asset inside X.
- Even if A is directly granted Writer on dataset D inside X, the ceiling on X is Reader, so A's effective permission is Reader.
This pattern is the central safety mechanism that catches permission leaks in one place. Permissions that a user has never been granted can't inherit · migrate their way in.
Layer 3: FGAC — narrowing within the same resource
While Role + Ceiling control access itself, FGAC controls what columns and rows are visible differently per user within the same dataset.
- Column masking — e.g. Within an HR dataset, show
salaryonly to the HR group. - Row filtering — e.g. Within a sales dataset, show each regional rep only their region's rows.
Authoring an FGAC policy is hands-on in Lesson 4. This lesson just fixes the placement: FGAC is the third layer that stacks on top of Role · Ceiling.
The starting point of permission grants
The operational rule that falls naturally out of the layering: permission grants always start from a collection.
The most common mistake when onboarding a new team is granting permissions at the dataset level. It's not that it doesn't work — but the collection ceiling often hides the effective permission. The first flow is always: define the collection the team will work on → grant a group role on that collection.
What you should be able to do after this lesson
- Name what each of Role / Ceiling / FGAC answers
- Internalize the ceiling effect on collections
- Apply the first rule — permission grants always start from a collection
Next lesson
Connect an external IdP (OIDC) for SSO and set up auto-provisioning on first login.