Users & Permissions

EntiHub uses Microsoft Entra ID for sign-in. Authorization is fine-grained by domain and entity, with optional row-level security for specific entities (in higher application tiers).

Authentication

• EntiHub uses Microsoft Entra ID exclusively for interactive and delegated access.
• Register the application in Entra ID and configure redirect URIs and token settings for your deployment hostnames.
• At least one app role gates entry; only principals with the assigned role receive a valid application session.
• Global administrator capabilities map to Entra app roles assigned to users or groups.
• Automation principals can authenticate via API keys (X-API-Key) managed in the Admin UI; permissions are evaluated the same way as for users by assigning rights to the API key name.

Permission levels

Permissions are defined directly in the EntiHub application under System → Permissions. Each permission assignment combines a principal (user or group), a scope, and a set of allowed actions.

Scope can be set at two levels:

• Domain — the assignment applies to all entities within the selected domain. Useful for broad access grants such as giving a team read access to the entire Finance domain.
• Entity within a domain — the assignment applies to one specific entity. Use this to grant or restrict access at a finer grain, for example allowing write access only to the Customer entity inside Finance.

When both a domain-level and an entity-level assignment exist for the same principal, the more specific entity-level row takes precedence.

Level	Capabilities
Admin	Manage entity definitions, deploy and redeploy, edit permissions and application settings.
Write	Create, read, update, and delete rows within granted scope.
Approve	Approve or reject pending changes where approval workflows are enabled.
Read	Read-only access to data and metadata within granted scope.
Read restricted	Read-only access to restricted columns data within granted scope.

Row-level security (RLS)

Professional and Enterprise tiers can attach an optional row filter to permission rows that target a specific entity.

• The filter uses the same bracket DSL as the Data grid and REST filter parameter.
• At query time the server applies RLS AND user filter.
• Global administrators bypass RLS for data access.
• RLS is stored per named entity; a domain-wide wildcard row does not carry entity-specific RLS.
• Configure RLS in the UI or via POST /api/v1/permissions using rowFilterDsl.
• Permissions YAML also supports optional rowFilterDsl for concrete entity names only.

Permission storage

• Permission rows live in the configuration schema alongside other MDM metadata.
• Sensitive identifiers and assignment material are stored using hashed representations (no-one can read or edit them in database).

YAML import/export

All permission assignments can be fully defined, exported, and re-imported using a YAML file. This allows you to version permissions in source control and promote the same setup across environments.

• GET /api/v1/permissions/yaml exports the current permission matrix as YAML.
• POST /api/v1/permissions/yaml imports a YAML document that replaces the full permission set.

CLI equivalents:

entihub permissions yaml-export
entihub permissions yaml-import --file permissions.yaml

Sample permissions YAML

permissions:
    - users:
            - alice@contoso.com
            - bob@contoso.com
        domains:
            - Finance
        entities:
            - Customer
            - Vendor
        actions:
            - read
            - write
            - approve
            - viewrestricted

    - users:
            - carol@contoso.com
        domains:
            - HR
        entities: []
        actions:
            - admin

Admin UI

• The permissions screen presents a tabular matrix where each row is one assignment.
• Columns typically include principal, domain, entity, effective rights, and optional RLS filter.
• Changes persist to the configuration store and take effect on the next authorization check.