Everything behind the operator pages is one audience, and deployment-wide settings need a second #4

New Issue

2026-09-21T07:18:03Z

cgalo5758 commented

2026-09-21 07:18:03 +00:00

The question

The console knows one application role, carried in the identity provider's token, and every page behind the operator prefix is open to whoever holds it. The daily work, people and organizations and grants and billing and the catalog, is not the same job as configuring the deployment: settings, integrations, identity. Is there a second role, an administrator, and what does each of the two see and do?

What depends on the answer

The deployment settings page, which should not be built before it is known who may open it; where the integrations pages and the setup checklist belong; and whether the console can show which people hold which console role, which it cannot do today because no role is recorded in its own database.

Options known so far

Two roles arriving through the same token claims, with a stated split: deployment-wide configuration to the administrator, the daily operator work to the operator.
One role, with configuration kept out of the console entirely and left to the deployment's environment.

Both roles would arrive the same way the current one does, so this is decided together with how a role is found in the token.

Decided when

The identity documentation names the roles, lists what each reaches, and the routes enforce that split rather than a single check for one role.

Migrated from status/issues.md at b7a0e15

## The question The console knows one application role, carried in the identity provider's token, and every page behind the operator prefix is open to whoever holds it. The daily work, people and organizations and grants and billing and the catalog, is not the same job as configuring the deployment: settings, integrations, identity. Is there a second role, an administrator, and what does each of the two see and do? ## What depends on the answer The deployment settings page, which should not be built before it is known who may open it; where the integrations pages and the setup checklist belong; and whether the console can show which people hold which console role, which it cannot do today because no role is recorded in its own database. ## Options known so far - Two roles arriving through the same token claims, with a stated split: deployment-wide configuration to the administrator, the daily operator work to the operator. - One role, with configuration kept out of the console entirely and left to the deployment's environment. Both roles would arrive the same way the current one does, so this is decided together with how a role is found in the token. ## Decided when The identity documentation names the roles, lists what each reaches, and the routes enforce that split rather than a single check for one role. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/identity area/operator-ui area/ops security labels 2026-09-21 07:18:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#4