User + group management — IdP-group ↔ portal-group mapping
Define IdP-group to portal-group mappings and grant collection permissions in bulk at the group level.
Lesson 2 automated adding users via auto-provisioning. This lesson nails down the next step — bulk permission grants at the group level. The one-by-one user permission flow breaks down once you cross 5 people.
Two kinds of group in D.Hub
- SSO (IdP) group — Managed by the external IdP. Example: Keycloak's Data Analytics Team, Azure AD's engineering. The IdP is the source of truth.
- Portal group — Managed by D.Hub. Either 1:1 mapped from an IdP group, or created as a portal-only bundle (e.g. Project A temporary members).
The principle is simple. Permission grants flow through IdP-group ↔ portal-group mapping → portal-group gets the collection role, in two steps.
Step 1: Mapping IdP groups
Go to Settings → Group Management in portal and click + Group mapping.
- IdP group name — The group identifier on the IdP. Example:
data-analytics(lowercase, hyphens recommended). - Portal group name — The internal name D.Hub uses. Separate from the alias.
- Alias — The locale-aware label users see. Example: Data Analytics Team.
Save, and users whose IdP claims include that group automatically become members of the portal group. Membership recomputes on every login — removing a user from the IdP group drops them from the portal group on their next login.
Step 2: Grant collection permissions to the portal group
Now the portal group becomes the unit of permission grant.
In the target collection's detail screen, open the upper-right ⋯ menu → Sharing & Permissions. Under + Add permission:
- Target — Pick Group → the portal group you just created
- Role — Choose Reader / Writer / Owner
Save, and every member of that group has the collection permission. The collection ceiling effect applies automatically — group members can't have higher than the ceiling on any asset inside the collection (Lesson 1).
Debugging — why doesn't this user have permission?
The most frequent operations question. Check in order:
- Is the user actually a member of that group on the IdP? (Check the IdP console.)
- Has the user logged in recently? (Membership recomputes on login.)
- Does the portal group hold permission on that collection? (Check Sharing & Permissions on the collection.)
- Isn't the ceiling on the collection narrower than the intended role? (Run the effective permission vs ceiling debug from Lesson 1.)
These four steps catch nearly every missing permission case.
What you should be able to do after this lesson
- The IdP-group ↔ portal-group mapping + alias division
- The two-step pattern — grant goes to a group → that group gets a collection role
- The 4-step permission-debugging checklist
Next lesson
Author your first FGAC policy combining column masking + row filtering within one dataset.