RBAC for Dex Users¶

StarlingX OpenStack supports group-based Role-Based Access Control (RBAC) for Dex-federated users. When enabled, Keystone processes OIDC group claims from the identity provider and maps them directly to OpenStack groups, allowing automatic role assignment based on group membership.

About this task

By default (claim_groups: false), all users authenticated via Dex are assigned to a single group (federated_users) with the member role on the federation project. This provides a simple, flat authorization model.

When claim_groups is set to true:

The OIDC scope is automatically expanded to include groups (i.e., openid profile email groups).
The federation mapping switches from default_mapping to groups_mapping, which maps the OIDC-groups claim directly to Keystone groups.
The OIDCClaimDelimiter (set to ; by default) ensures that users belonging to multiple groups are correctly parsed by Keystone.
The bootstrap script creates the groups, projects, and role assignments defined in the groups list.

Enable RBAC¶

Prerequisites

Basic Dex federation must be working first (claim_groups: false mode) — verify users can log in via Horizon WebSSO before enabling group-based RBAC.
The identity provider connected to Dex (e.g., LDAP, Active Directory) must have groups configured and users assigned to them.
Dex LDAP connector must include a groupSearch configuration that queries group membership (see [Step 2: Configure Dex LDAP Connector](#step-2-configure-dex-ldap-connector)).
StarlingX OpenStack group names defined in the groups list below must match exactly (case-sensitive) the group names returned by Dex in the OIDC groups claim.
The endpoint_domain must be configured (required for all Dex federation).

The endpoint_domain is a StarlingX parameter under the StarlingX OpenStack service. To configure it run the following command in the StarlingX controller:
```
~(keystone_admin)$ system service-parameter-add openstack helm endpoint_domain=<your-domain.com>
```
To verify its value, run:
```
~(keystone_admin) $ system service-parameter-list --service openstack --section helm
```

To enable RBAC with Dex, add the following overrides to the StarlingX OpenStack Keystone Helm overrides:

conf:
  federation:
    dex_idp:
      enabled: true
      claim_groups: true
      groups:
        - name: developers
          project: dev_project
          role: member
        - name: operators
        - name: security
          project: sec_pro
          role: admin
        - name: architects
          project: dev_project
          role: admin

This will:

Create OpenStack groups: developers, operators, security, architects
Create projects: dev_project, operators_project (auto-generated as <name>_project), sec_pro
Assign roles (admin/member) to groups on their respective projects
Users logging in via Dex will automatically be assigned to their matching StarlingX OpenStack groups based on the OIDC groups claim.

If StarlingX OpenStack groups, projects, and role assignments are already configured (or will be created manually), the minimal override is:

federation:
  dex_idp:
    enabled: true
    claim_groups: true  # Enable group-based authentication

This enables group-based mapping without the bootstrap creating any groups. The groups list defaults to [] and the bootstrap will only create the identity provider, mapping, and federation protocol.

Important

When using this minimal override, all required OpenStack groups must exist in Keystone before users attempt to log in. Users belonging to groups that do not exist in Keystone will fail authorization.

For a complete step-by-step guide including LDAP group creation, DEX connector configuration, and verification procedures, see [Group-Based RBAC with LDAP/AD — Operational Guide](#group-based-rbac-with-ldap–operational-guide).

Group Mapping¶

The groups_mapping uses a direct name-matching approach: OpenStack groups must have the same name as the groups configured in the identity provider connected to DEX.

For example, if a user belongs to LDAP groups “developers” and “operators”, they will be automatically assigned to StarlingX OpenStack groups with the exact same names (“developers” and “operators”).

The mapping rule:

[{
  "local": [
    {"user": {"name": "{0}"}},
    {"groups": "{1}", "domain": {"name": "Default"}}
  ],
  "remote": [
    {"type": "OIDC-email"},
    {"type": "OIDC-groups"}
  ]
}]

{0} = User’s email from the OIDC email claim (used as the Keystone username)
{1} = User’s groups from the OIDC groups claim (passed directly to Keystone, delimited by ;)

This means the group names defined in the Helm overrides groups list must match the group names that exist in your identity provider. The bootstrap script will create these groups in OpenStack with the associated projects and roles. Groups can also be created manually later if nothing is added to the groups override option.

Switch between modes¶

Switching from claim_groups: false to true requires defining the groups list and reapplying WRO. The bootstrap will create the new groups and the mapping will switch automatically.
Switching from claim_groups: true to false will revert to the single-group model. Previously created groups and role assignments will remain in Keystone but will no longer be used by the federation mapping.