Permission model at a glance (7 min)

By the end of this tutorial

• You can answer "who can see and touch what?" in portal's own vocabulary.
• You have a single table mapping AD/SAML/OIDC background knowledge to D.Hub's three permission layers — role, collection ceiling, and FGAC.
• You have enough confidence to fill the permissions section of a one-page security and legal review with no follow-up needed.

One-line summary — D.Hub permissions are decided by the intersection of three layers: (1) a three-tier role on each resource (Owner/Writer/Reader), (2) the collection as a ceiling on its child assets, and (3) FGAC policies that hide columns or filter rows differently per user even on the same dataset.

1. Mapping prior knowledge (1 min)

If you are arriving from enterprise IT vocabulary, keep this mapping in mind.

These term mappings are not just guidance internal to this tutorial — they are the literal labels on portal's screens. You can confirm them by going to System → Settings → Users / Groups / Authentication in the sidebar.

2. The three-tier role per resource (1 min 30 sec)

For each resource (collection, dataset, code, pipeline, knowledge, dashboard, agent, ontology) you grant a single role to a user or group.

• Roles are cumulative. Owner includes Writer, and Writer includes Reader.
• The user who created a resource is granted Owner automatically. From there, the Owner grants and revokes access for other users and groups.
• Grants are made to users or groups. Granting to a group means membership changes apply to access immediately.

3. The collection ceiling model (1 min 30 sec)

A role on a collection acts as a ceiling on its child assets. This is the single most distinctive trait of the D.Hub permission model, and it is the one most often missed during a review.

• A user who is a Reader on a collection cannot become a Writer on a dataset or dashboard inside it.
• When granting permission on a child asset, any role that exceeds the user's collection role is blocked with a ceiling badge.
• Lowering or removing a user's role on the collection propagates downward automatically. The impact scope is shown in a confirmation modal just before the change applies.

The operational implication: before granting or revoking permission on a single dataset, you should look at the collection's membership first. Skipping that step is what produces the recurring "I gave them Writer but they can't edit" support ticket.

4. Fine-grained policies — same dataset, different views (1 min 30 sec)

If a role decides "can this user see this dataset", policies (FGAC) layer column masking and row filters on top so that the same dataset shows a different scope or shape to different users and groups.

• Column masking — choose from hide column, replace with NULL, fixed text, leading or trailing N characters, or hash (SHA-256/MD5). The schema stays the same; only the values change per subject.
• Row filters — column · operator · value conditions grouped by AND/OR, nestable up to three levels. Equivalent to a WHERE clause.
• Scope — per dataset. Managed from the dataset detail view's Data access policies tab. Adding, editing, and deleting policies requires the delete permission (Owner) on that dataset.

Policies apply at read time (SELECT). The key operational point is that policies don't block access — they narrow the result on top of access.

5. Authentication separates from authorization (30 sec)

• D.Hub keeps authentication (who you are) and authorization (what you can do) managed separately.
• Authentication uses one of two paths: local login or SSO (OIDC). With SSO configured, you can register and sync IdP users and groups.
• For SSO users, no password is stored in D.Hub. Name and email are owned by the IdP.
• The user type (role) has three tiers: Admin / Manager / User. Only admin can reach the user, group, and authentication management screens.

The SSO onboarding flow and automation auth (OIDC clients) are covered in a separate tutorial — SSO and account provisioning in one page.

6. One-page review checklist

A format you can paste into a security and legal summary as-is.

• Authentication — Local and SSO (OIDC) operate side by side. Emergency local account policy locked in.
• User type — Of admin / manager / user, the holders of admin are explicitly named.
• Role (resource permissions) — Owner / Writer / Reader. The creator becomes Owner automatically.
• Collection ceiling — The collection role acts as a ceiling on child assets. Revoking propagates downward.
• FGAC — Column masking and row filters at the dataset level. The first list of in-scope datasets is locked in.
• Group practice — Prefer granting to groups over users. IdP group one-way sync is assumed.
• Change history — Resource change flow is visible from portal's Recents view (/recents) as a first cut. A dedicated security audit log or export needs a separate inquiry.

Next steps

• If onboarding the authentication flow and automation auth (OIDC clients) is the next agenda, head to SSO and account provisioning in one page.
• For the hands-on policy authoring and rollout flow for FGAC column and row masking, Column- and row-masking policy operations is the operational version of item 5 on this page.
• To see how the permission model surfaces inside an analyst's flow, lesson 06 — Sharing and next steps of the Analyst Path shows the same permission dialog opening from the analyst's seat.