RBAC in the Cadence Web

[ribaraka]

Hi! Re #6706.
Cadence does not provide built-in access control for its Web. As a result, there is no mechanism for authorized user to interact with UI. While it’s technically possible to modify the code and rebuild the client, this approach is inconvenient and not practical for most users.
Our goal is to deliver out-of-the-box RBAC for the Cadence Web UI, complementing the backend access checks and improving user experience.
As I see it, Cadence handles most access control on the backend. Each API endpoint is associated with a specific permission level (admin, write, read). A domain defines who can read or write by specifying groups in its metadata (e.g., WRITE_GROUPS, READ_GROUPS). This means authorization is enforced server-side. So, it is need to issue a JWT that contains the user’s group memberships. Cadence then checks those groups against the domain’s allowed groups to determine access. For example:

Domain Setup
name: "finance-payments"
READ_GROUPS: ["worker"]
WRITE_GROUPS: ["payer"]

Meaning:
worker → can READ
payer → can READ + WRITE

User JWT Examples
User 1: Anna (worker — read only)
{
"name": "anna",
"groups": ["worker"]
}

User 2: Ben (payer — read + write)
{
"name": "ben",
"groups": ["payer"]
}

We can have those role respectevly:
• Cadence Admin - Full access to all domains (read and write) - a superuser role with no restrictions. We can have in JWT Claims the Admin:true without adding any group (+ it aligns with backend validation);
• Domain Admin – Full access (read/write) only to specific authorized domain(s) - the Admin value is false, specify name (i.e. group) of domains.
• Domain Viewer- Read-only access to specific authorized domain(s). They can view workflows and histories in those domains but cannot mutate state (no workflow start/terminate, etc.) - the Admin value is false, specify name of domains.
• Public (a user without any authorization other than access to Cadence-web) - here we probably only show domains not restricted by group.

The scope: add UI-layer awareness of Cadence backend auth without inventing new policy surfaces. The Web should only propagate tokens, reflect capabilities in UX (enable/disable/hide). Backend remains the source of truth; every GRPC call is authorized by Cadence.

Cadence-Web doesn’t implement its own auth; it piggybacks on Cadence’s JWT-based authorization:

• Token source: An upstream identity provider issues RS256 JWTs containing Cadence-specific claims (groups or admin flag). The Cadence server validates the token signature against a configured public key and enforces access per endpoint/domain based on those claims and domain metadata.
• Propagation: Cadence-Web accepts a JWT and stores it. On every server-side request, middleware reads the token from header/cookie and forwards it to Cadence over gRPC metadata as cadence-authorization.
• Cookie endpoint (app/api/auth/token): POST {token} to set an HttpOnly, Secure, SameSite=Lax cadence-authorization cookie; DELETE to clear.

UI enforcement:
- Login button to paste jwt token.
- Workflow actions use access to enable/disable with “Not authorized” (for read-only users).
- Domain list hides domains without read access.
- Unauthenticated: show only open domains if no groups are required.

Additional feature:
• Each authenticated user is associated with one or more roles (from the four above). For example, a user could be a Domain Admin for domain X and a Domain Viewer for domain Y.
• Caching: cache user roles in the session to avoid repeated computation. We may also cache the filtered domain list for the user in the session. For example, on login we can compute “allowedDomains” array and store it, so when the UI needs to display domains, it just uses that array (or intersects it with fresh ListDomains results from server). If domains are added/removed, a user might need to relogin to update their view (through the Cookie endpoint).

[Assem-Uber]

Thanks @ribaraka kicking off the discussion, i went through the proposal and have few questions:

• I didn't completely get the use of having the 4 roles and how they work with the groups.
• What is the session timeout behaviour on web ?

Login button to paste jwt token.

• From UX perspective redirecting to a login page is much simpler than getting & pasting the JWT.

Unauthenticated: show only open domains if no groups are required.

• Is there a use case for supporting viewing domains for unauthenticated users ? this may slightly complicated the UX

[ribaraka]

Thanks for instant review!

I didn't completely get the use of having the 4 roles and how they work with the groups.

This mapping I derived from the backend code and logically comparing it to the four roles initially proposed in the GitHub issue.
So, domains have this concept on the backend:

• READ_GROUPS – list of group labels allowed to read the domain
• WRITE_GROUPS – list of group labels allowed to write to the domain

Those group labels are arbitrary strings defined by the operator (e.g. "worker", "payer", "team-A", etc.). A user’s JWT just carries a list of groups, and Cadence checks:

• Does any of the user’s groups appear in READ_GROUPS for this domain? → then reads are allowed.
• Does any of the user’s groups appear in WRITE_GROUPS for this domain? → then writes are allowed.

From that, the Web UI can derive more human-friendly “roles” per domain:

• If user only matches READ_GROUPS → we label them as Domain Viewer for that domain.
• If user matches WRITE_GROUPS (and hence implicitly can read as well) → we label them as Domain Admin for that domain (i.e. full access, but only for those domains).

On top of that, there is a separate Cadence Admin concept (also already supported on the backend):

A dedicated flag/claim in the token admin:true means Cadence Admin - effectively “Domain Admin for all domains”, no need to list all domain groups explicitly.

So the mapping is:

• READ_GROUPS → Viewer (per domain)
• WRITE_GROUPS → Domain Admin (per domain)
• admin flag → Cadence Admin (global)
• public just public. in the initial issue it says: "Public (a user without any authorization other than access to Cadence-web)", so I just assumed if a domain doesn’t specify any groups at all it could be treated as public read-only. But we can just make all page Unauthenticated = no domain access (maybe just a message like “no token, please log in”).

What is the session timeout behaviour on web ?

To keep the scope small, the Web doesn’t introduce its own separate session concept – it treats the JWT as the session. The token’s exp claim is the effective session timeout. When the token expires, Cadence server will reject calls using that token.
If we want a web-specific idle timeout, that can be a follow-up (backloged?).

From UX perspective redirecting to a login page is much simpler than getting & pasting the JWT.

The “paste JWT” login button in the proposal is mainly meant as a minimal, self-contained default that works without integrating an IdP, and a dev path.
In my understanding, a typical production setup we’d expect an upstream proxy / IdP to handle the actual login/redirect flow, and
inject the JWT into a header or cookie before the request reaches Cadence-Web.

Is there a use case for supporting viewing domains for unauthenticated users ? this may slightly complicated the UX

I don’t aware of any strong real-world use case for unauthenticated users seeing domains and I’m fine to drop that for the initial version. We can keep RBAC strictly “token → access, no token → no access”; the UI can show a clear message like “No valid token / not authorized” instead of listing any domains.

[Assem-Uber]

Now i see what does Roles means in that context. While i don't see this as RBAC, roles here represents more the user's permissions per resource (labels for permissions). It is better to avoid referring to it as RBAC since it usually refers to a different approach. (We can revisit the description of the issue)

For session timeout, it make sense to depend the exp of JWT. There is no need for idle time session timeout too, I'm more concerned about what happens for the user when requests starts to get rejected because of expiration of the token. As a user i would expect to that notifies me about the expiration and allows me to get relogin/add a new token. We can have different assumptions how to obtain a new token but user experience is almost the same in all (a page to login & expiration/session timeout). For production setups that automatically injects tokens, we need be able to disable the builtin behaviour.

I also lean towards simplifying the approach and have no token → no access.

[ribaraka]

I’ve implemented the initial version of this feature. I run several use cases manually and it appears to be working so far.
I’m currently addressing the failing test cases, but I’d appreciate a preliminary review to confirm I’m going in the right direction and not missing anything fundamental. The PR: cadence-workflow/cadence-web#1108
Thanks!