SSO and account provisioning in one page (8 min)

By the end of this tutorial

• You have a single diagram for the standard D.Hub's SSO sits on (OIDC) and the direction sync flows between IdP and D.Hub.
• You can distinguish three identity sources — local user, IdP user, OIDC client for automation — along with their operational risks.
• You have enough confidence to fill the authentication and provisioning section of a compliance and security one-pager.

One-line summary — D.Hub's SSO follows the OIDC standard, user and group registration runs IdP → D.Hub one-way, and automation uses a separately issued OIDC client whose secret is exposed once. Keeping an emergency-access local account even in an SSO environment is the standard recommendation.

1. Authentication separates from authorization (30 sec)

D.Hub keeps authentication (who you are) and authorization (what you can do) as separate concerns. This tutorial covers the authentication axis only — for permissions, roles, and policies, see Permission model at a glance as the companion.

2. SSO login flow (1 min 30 sec)

Once SSO is configured, the login screen shows an SSO sign-in button alongside the local one. When a user clicks it, D.Hub redirects to the IdP, takes the IdP authentication result, and creates a session.

User  → D.Hub : click "SSO sign-in"
D.Hub → IdP   : login request (redirect)
IdP   → User  : IdP login screen
User  → IdP   : submit credentials
IdP   → D.Hub : return authentication result
D.Hub → User  : signed in to D.Hub

Core facts:

• Standard — OIDC (OpenID Connect). Any standard-OIDC IdP (Keycloak, Azure AD/Entra ID, Zitadel, etc.) can integrate. Which IdP is wired in at deploy time shows up as the provider name on the login screen and on the user registration button.
• No password stored — SSO users' passwords are not stored on D.Hub; the IdP is also authoritative for basic profile fields like name and email.
• Local and SSO co-exist — Local accounts can still live on the system after SSO is configured. Keeping an emergency-access local account is the standard operational recommendation (so an admin can still sign in if the IdP fails).

3. User registration — local vs IdP (1 min 30 sec)

Sidebar System → Settings → Users (/settings/users). Only admin-type users can enter.

After registration, the admin assigns D.Hub-internal attributes:

• Type (role) — One of Admin / Manager / User. Determines reach into management screens.
• Group — A single user can be in multiple groups at once. Groups are the unit of permission grants.
• Active / inactive — Toggled instantly.

Operational notes:

• Local user passwords are at least 8 characters. An admin can issue a password reset, but cannot apply it to their own account.
• For SSO users, the row action Sync refreshes the profile against the IdP. Users deleted on the IdP get a notice in D.Hub.

4. Group registration — IdP → D.Hub one-way (1 min 30 sec)

Sidebar System → Settings → Groups (/settings/groups). Admin only.

• Local groups — Created via Create group. Can only hold local users.
• SSO (IdP) groups — Brought in via Register IdP group. Updated via Sync after registration.

Remember just one fact — group registration and sync flow IdP → D.Hub. Changing membership on D.Hub does not push back to the IdP. So membership changes on SSO groups should be made on the IdP side as the standard flow.

Member assignment happens from the user screen, not the group screen. Edit the user and add or remove their Group field.

Granting permission to a group means a membership change applies to access immediately — the single biggest lever for operational efficiency.

5. OIDC clients for automation (1 min 30 sec)

When an automation script or external system has to call the D.Hub API without a human login, you issue an OIDC client.

Entry: sidebar System → Settings → OIDC clients (/settings/oidc-clients).

Operational risks and conventions:

• The secret is shown only at creation or rotation — moving it into a secure secret store (e.g. an in-house vault) immediately is the standard practice. No screen will show it again.
• One client per system — Reusing a single client across multiple automations widens the blast radius of any incident. One client per system is the operational recommendation.
• Secret storage — Credentials used by scripts, connectors, and similar can be stored and referenced from a separate Secrets screen (/settings/secrets).
• Revocation flow — On exposure, role change, or system retirement, rotate or delete the client. A rotation exposes a new secret exactly once, just like creation.

6. One-page review checklist

A format you can hand to security and legal right after the adoption meeting:

• Standard — OIDC. Current IdP locked in (e.g. Keycloak / Entra ID / Zitadel).
• Login paths — Which is primary, local or SSO? Holders of the emergency-access local account are named.
• Provisioning direction — IdP → D.Hub one-way. Channels where D.Hub creates its own identities are listed (local users, automation clients).
• Type distribution — Admin and manager holders are explicitly named. Admin reaches users, groups, authentication, and system settings.
• Group practice — IdP is authoritative for SSO group membership. The risk of forgetting that when editing groups on D.Hub is acknowledged.
• Automation auth — Issue and rotation procedure for OIDC clients. The vault-loading SOP under the secret-exposed-once policy is locked in.
• Account revocation — Whether deactivating an SSO user is enough or deletion is needed, decided per internal policy.

Next steps

• For permissions, roles, and policies at the same page depth, see Permission model at a glance.
• Once users and groups are registered and synced, narrow further down to dataset columns and rows via Column- and row-masking policy operations — if SSO is the axis that binds who, FGAC is the axis that narrows what.
• Every screen and field name in this tutorial matches portal's System → Settings sidebar tree. When portal labels change, the labels here sync in the same round.