Allow operators to define custom roles and the permissions they grant

[ramonsmits]

Is your improvement related to a problem? Please describe.

ServiceControl 6.18.0 introduced role-based access control with three built-in roles — reader, writer, and admin. The set of roles, and the permissions each role grants, are fixed in the product. An operator integrating their identity provider can only map existing groups/claims onto one of those three names; they cannot define a role of their own, nor change which permissions a role grants.

Three coarse tiers do not match how many organisations actually delegate access to the platform. Real segregation-of-duties needs are more granular than "read everything / operate everything / configure everything", for example:

• An on-call engineer who may retry and archive failed messages but must not manage notifications, licensing, or edit message bodies.
• An auditor who may view audit history and the event log but has no operational capability.
• A team that may operate errors for their own work but must not see throughput or licensing.

Because the roles sit between these needs, operators are forced to choose the closest fixed tier and over-grant (hand out writer/admin when only a slice was required) or under-grant (deny people access they legitimately need to do their job). Over-granting directly undermines least-privilege and segregation-of-duties expectations — precisely the controls that security reviews, compliance audits, and enterprise procurement scrutinise.

The impact is felt most by:

• Regulated or security-conscious customers operating under a least-privilege mandate.
• Larger operations teams that differentiate responsibilities across people and shifts.
• Any customer whose existing IdP group structure does not map cleanly onto exactly three tiers.

Today the only remedies are unsatisfactory: over-grant and accept the risk, or request a product change — but since the role/permission sets are baked into the product, one customer's policy cannot be accommodated without changing the shipped behaviour for everyone.

Describe the suggested solution

Operators should be able to define their own roles and choose which permissions each role grants, drawn from the platform's existing permission catalogue, so that access can be aligned with an organisation's actual segregation-of-duties policy rather than three predefined tiers.

This issue is intentionally about the problem and the capability, not the mechanism. How roles are defined and managed (configuration, an administrative UI, IdP-driven, etc.) is a design decision to be worked out separately.

Out of scope for this issue: resource scoping — restricting a granted permission to a subset of resources (e.g. only sales.* vs billing.* queues).

Describe alternatives you've considered

• Keep mapping IdP groups onto the three fixed roles (current state). Insufficient — it forces over- or under-granting whenever an organisation's needs fall between the tiers.
• Product change per customer request. Does not scale, and cannot satisfy differing customer policies simultaneously because the roles are compiled into the product.