Authentication and access control

D.Hub manages login (authentication) and resource access (permissions) separately. Log in using a local account or organization's integrated login (SSO), and role-based permissions and granular policies are applied to resources.

Login method

The login screen offers two methods:

• Local Login: Log in with your email and password.
• SSO Login: If the organization's ID provider is linked, the SSO Login button also appears. Pressing the button takes you to the ID provider's login screen and back to D.Hub.

If you configure single sign-on (SSO), you can log in directly using your organization account without a D.Hub password.

SSO (OIDC)

Single sign-on (SSO) follows the OpenID Connect (OIDC) standard. When you log in with SSO, D.Hub creates a login session with the information received from your identity provider.

• SSO users do not save their passwords in D.Hub, and basic profiles such as name and email are managed by the identity provider.
• The administrator registers the user/group of the ID provider on the User Management·Group Management screen and specifies the type (role) used in D.Hub.

What identity providers do you support?

You can integrate identity providers that support standard OIDC (e.g. Keycloak, Azure AD/Entra ID, Zitadel, etc.). Check which ID provider is currently linked by the provider name displayed on the login screen and the user/group registration button.

Authentication for automation and integration (OIDC client)

If an automation script or external system needs to call the D.Hub API without a human logging in, use OIDC Client. Client issuance and management is handled by the administrator by going to the System → Settings → OIDC Client menu in the sidebar.

• The client's secret key is visible on the screen only once when created or reissued, so keep it separate in a safe place.
• Credentials to be used in scripts or connectors can be saved and used in a separate Secret storage screen.

Access control (role-based)

Access to a resource is determined by the role between the user/group and the resource. Roles are granted to users or groups in the Sharing and Permissions screen of a resource.

Role	View	Edit	Delete/Permission Management
Viewer	✅
Editor (writer)	✅	✅
owner	✅	✅	✅

• Roles are cumulative. The owner has editor permissions, and the editor has viewer permissions.
• The user who created the resource automatically becomes the owner, and the owner also grants or withdraws permissions from other users and groups.

Manage permissions with groups

If you assign roles to groups instead of individual users, access rights automatically change as group members change.

Group "data-team" → Collection "sales-data" (Editor)
├── alice (member) → can edit sales-data
├── bob   (member) → can edit sales-data
└── carol (member) → can edit sales-data

Column/row level control

After opening resource access by role, if you want different visible columns and rows for each user/group even in the same dataset, use a policy, that is, granular access control. For more information, please refer to Policy Overview.

Next steps

document	Description
User Management	User inquiry/creation, ID provider user registration/synchronization
Sharing and Permissions	How to assign roles to resources
Policy Overview	Granular access control at column/row level