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 can map AD/SAML/OIDC background knowledge to D.Hub roles, inherited collection permissions, 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 — A collection role is the minimum permission inherited by its child resources. A collection member can receive a higher role on a specific child, while FGAC narrows the columns and rows visible in an accessible dataset.

1. Mapping prior knowledge (1 min)

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

You can confirm the identity-management labels under Settings → Users and Settings → Groups. The current portal does not provide a separate Authentication settings page. Upstream SSO provider connection is deployment configuration, while Settings → OIDC Clients manages credentials issued to external systems rather than that connection.

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 permission floor (1 min 30 sec)

A role on a collection is the minimum permission inherited by every child resource. A collection member can also receive a higher direct role on a specific child.

• A collection Reader can read every child resource.
• If that member receives Writer directly on one dataset, they can edit that dataset while remaining Reader on other children.
• A subject must first be a collection member before receiving a direct role on a child resource.
• Lowering the collection role does not erase a valid higher direct role on a child.
• Removing collection membership removes inherited access and cleans up that subject's direct child grants.

For example, if Mina is Reader on collection A and Writer on dataset B, Mina can read the other resources in A and edit B. When troubleshooting, check collection membership → inherited role → direct child role in that order.

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 replace with NULL, fixed text, leading or trailing N characters, or hash. 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. The dataset owner or an admin can add, edit, and delete policies.
• Bypass — FGAC does not apply to admins or the dataset owner. Verify a policy with a Reader or Writer account.

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.
• Account type has three tiers: Administrator / Manager / User and controls the account's operational scope. Only an Administrator can reach the user, group, and OIDC client management screens.
• Creating collections or connectors and importing scenarios requires a Manager or Administrator. A User can still create collection-scoped assets such as datasets, Code, pipelines, and dashboards where authorized.
• Account type and resource role are separate axes. The Owner / Writer / Reader role granted on each collection or asset determines management, editing, and viewing there.

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

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 decided.
• User type — Administrator / Manager / User operational scopes and Manager-plus creation tasks are distinguished.
• Role (resource permissions) — Owner / Writer / Reader. The creator becomes Owner automatically.
• Inherited collection role — The collection role is the minimum permission on child resources. Members may receive a higher role on a specific child.
• Membership removal — Removing a collection member removes inherited access and cleans up that subject's direct child grants.
• 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. Record whether the connected IdP is read-only or write-capable for group membership.

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 (8 min).
• For the hands-on policy authoring and rollout flow for FGAC column and row masking, Column and row masking — from FGAC policy authoring to rollout is the operational version of item 5 on this page.
• To see how the permission model surfaces inside an analyst's flow, Sharing, the AI Assistant, and what to learn next of the Analyst Path shows the same permission dialog opening from the analyst's seat.