Feature request / design concern: Custom roles require replacing built-in settings bundles

[ksk0]

I am testing OCIS with OIDC authentication, auto-provisioning, and role assignment from OIDC claims.

My setup is roughly:

• Azure AD / Entra ID as the user source
• Keycloak as OIDC broker/proxy
• OCIS using Keycloak as the OIDC provider
• OCIS role assignment driven by OIDC groups
• GRAPH_ASSIGN_DEFAULT_USER_ROLE=false, so the OIDC role assignment is authoritative

This works well with built-in roles. However, while testing custom roles I ran into what seems to be a structural problem with the current custom role mechanism.

The immediate reason I started testing custom roles was simple: I wanted to give a different class of users a different behavior/quota. That led me to custom roles and SETTINGS_BUNDLES_PATH.

The problem is that SETTINGS_BUNDLES_PATH appears to replace the entire settings bundle set, rather than only adding custom roles or overlaying specific role definitions.

This means that if I create a JSON file with only my custom role definitions, the built-in role/settings bundles disappear from the effective configuration. In my testing, this caused unrelated user settings to break.

For example, after enabling a custom bundle file, users could no longer change some profile/settings values such as language, notification preferences, or WebDAV display preferences. OCIS logged errors like:

bundleID '2a506de7-99bd-4f0d-994e-c38e72c28fd9' not found

This was not a permission problem in the custom role itself. The underlying settings bundle was simply missing because my custom bundle file replaced the built-in bundle list.

To make things work again, I had to extract the built-in bundles from the OCIS metadata/blob storage, reconstruct a full custom bundle JSON containing:

• built-in role definitions
• built-in profile/settings bundles
• my additional custom role definitions

After doing that, the system worked as expected.

However, this creates a serious operational concern.

Custom roles are part of authorization, and roles are consulted for many core user actions. Therefore, role definitions and related settings bundles are not just optional UI configuration; they are part of the system’s effective authorization/settings model.

With the current mechanism, using custom roles means the administrator effectively takes ownership of a full copy of OCIS internal settings/role bundle definitions.

That is fragile for upgrades.

If a future OCIS version adds new permissions, new settings bundles, new profile settings, new role capabilities, or changes built-in role behavior, a site using SETTINGS_BUNDLES_PATH will not automatically inherit those changes. The local custom bundle file can silently become stale.

The administrator then has to repeat a cumbersome process on every OCIS upgrade:

1. Start or inspect a clean OCIS instance of the new version.
2. Extract the current built-in bundle definitions.
3. Compare them with the previous version.
4. Rebuild the local custom bundle file.
5. Merge custom roles into the new bundle set.
6. Test that unrelated settings still work.
7. Test that role behavior and permissions still match expectations.

This feels risky for a production system. It is especially concerning because OCIS may be used with many users, many spaces, and large amounts of data. Authorization/settings definitions should ideally remain vendor-maintained and migration-safe unless explicitly overridden.

From an operator perspective, the current model makes a relatively small customization require maintaining internal OCIS bundle definitions across upgrades.

I think a safer model would be one of the following:

1. Additive custom roles

   Load built-in bundles first, then load additional custom roles from a separate path, for example:

   SETTINGS_CUSTOM_ROLES_PATH=/etc/ocis/custom-roles.json
   

   This would not replace built-in settings bundles.

2. Overlay/merge semantics

   Keep built-in bundles by default, and allow custom bundle files to override only explicitly matching IDs or add new IDs.

   For example:

   built-in bundles
   + custom overlay
   = effective bundle set
   

   This would avoid requiring admins to copy all built-in definitions.

3. Role inheritance

   Allow a custom role to inherit from a built-in role and only add/remove selected permissions.

   Example conceptually:

   limited-user:
     inherits: user
     remove:
       - SomePermission
     add:
       - SomeOtherPermission
   

   This would avoid copying the full user role definition and becoming stale after upgrades.

4. Separate policy mechanisms for things that are not really role capabilities

   Some behavior may not need to be tied strictly to roles. For example, quotas or similar policy values could potentially be mapped from groups/OIDC claims independently of role capability definitions.

   Roles describe system capabilities. But not every administrative policy necessarily has to require creating a new role.

The current implementation makes custom roles technically possible, but operationally fragile. It is easy to accidentally remove required built-in settings bundles, and even when configured correctly, the result is version-coupled to the OCIS release from which the built-in bundles were extracted.

Could you clarify whether this behavior is intentional and supported for production use?

More specifically:

• Is SETTINGS_BUNDLES_PATH intended to replace the full built-in bundle set?
• Is there a supported way to add custom roles without redefining built-in bundles?
• Is there a recommended upgrade procedure for installations using custom roles?
• Are there plans for additive custom roles, overlay semantics, role inheritance, or some other safer customization mechanism?
• Should admins treat custom role bundle files as version-specific artifacts that must be regenerated after every OCIS upgrade?

Any guidance on the intended future direction would be appreciated.