[Feature Request]: PRISM user roles and permissions

[wadhwamatic]

Provide a clear and concise description of what you want to happen.

PRISM user roles and permissions (draft for discussion)

Summary

This issue proposes a minimal v1 role and permission model for PRISM to unblock current work on authentication, dashboard editing, and gated deployments. The goal is a model simple enough to implement now, while remaining compatible with broader WFP identity and access work as it matures.

Proposed roles

Admin — full access to PRISM admin and configuration workflows. This will be limited to just Amit for now

Editor — can author and update dashboards, but cannot manage users or system-wide settings. There would be a handful of these users in WFP HQ, and one per country office

Viewer — can access gated content but cannot modify it

Public / Unauthenticated — access to non-gated content only.

Permission matrix

Capability	Admin	Editor	Viewer	Public
Access backend admin	✅	❌	❌	❌
Create dashboard config	✅	✅	❌	❌
Edit dashboard config	✅	✅	❌	❌
Publish changes	✅	✅	❌	❌
View gated content	✅	✅	✅	❌
Manage deployment settings	✅	❌	❌	❌
Manage users/roles	✅	❌	❌	❌

Deployment-scoped permissions

Roles are scoped per country/deployment — e.g. a user who is Editor for Myanmar only, or Viewer for one restricted deployment but not others.

Gated content

PRISM content is non-gated by default.

As of now, we have two types of gated content. In Myanmar, the entire application is gated. WFP SSO allows access via OAuth. This same capability should exist via CIAM.

We also have layer-level gating in the case of Cambodia's Kobo data layers. @ericboucher - I need a reminder on how those credentials were established. Did we just copy over DMP? Ideally this can migrate to the new CIAM approach

Open questions

• With the exception of Admin, should HQ Editors be able to create / edit country-level content?
• Do we need deployment-scoped permissions in v1, or can that come later?
• Do roles live in CIAM, or in an application-layer system PRISM controls?
• Which permissions are needed for the first dashboard editing workflow specifically?

Next steps

• Confirm proposed roles with Cam against current implementation needs
• Resolve open questions above before or during the next dev sync
• Review with Francesco and Valentin for alignment with broader WFP identity/access work

Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.

No response

[c-mac]

Answers:

• Roles will live application side, and we can make those easily editable by the admin role
• I don't view deployment-scoping as particularly challenging so I'd push for it for v1. If we didn't have it, that would presumably mean that a viewer could view all deployments as opposed to whichever country they're supposed to be assigned to which seems... not ideal?

Some questions:

• Does create / edit dashboard config exclusively live in the Prism UI frontend (not the admin app)?
• Could you elaborate on what "publish changes" means? Does this determine which configs to publish, which then allows viewers to select from a list of published dashboards?
• Is part of the goal with the auth migration to treat all countries equal underneath the CIAM umbrella? Meaning no more country-specific gating logic (like Myanmar)? This permission scares me a little bit because it seems like the only one that differs on a per-country basis compared to the rest, so I'd like to understand the full breadth of what we mean by gated content
• What kind of functionality comes from the "manage deployment settings" role?
• What's the significance of "first dashboard editing workflow"? Seems to me that these permissions would be the same as the create / edit dashboard config role

[wadhwamatic]

@c-mac - responses to your questions:

• Does create / edit dashboard config exclusively live in the Prism UI frontend (not the admin app)?

This is the plan. I see a path down the road where we'd want to have all admin tasks in the admin app. But we need more consideration of future tasks in the admin app how well this will work.

• Could you elaborate on what "publish changes" means? Does this determine which configs to publish, which then allows viewers to select from a list of published dashboards?

Yes, exactly that. Publish means it's visible to users via PRISM

• Is part of the goal with the auth migration to treat all countries equal underneath the CIAM umbrella? Meaning no more country-specific gating logic (like Myanmar)? This permission scares me a little bit because it seems like the only one that differs on a per-country basis compared to the rest, so I'd like to understand the full breadth of what we mean by gated content

We still need to support country-specific (and layer-specific) gating logic. The vision is that all WFP country offices will have their own version of PRISM that is available only to WFP users. Government / public facing versions of PRISM would not be gated. So far, the versions of PRISM we've developed have been for government / public access with the exception of Myanmar.

Issue #1763 will facilitate the ability to create PRISM for all WFP country offices. In some countries, we'll have a version of PRISM for internal WFP use and a version of PRISM for public use. We'll need to support that through separate configurations, i.e. COUNTRY=wfp-mozambique vs COUNTRY=mozambique.

• What kind of functionality comes from the "manage deployment settings" role?

As of now, just setting app-level restriction (i.e. "require SSO login")

• What's the significance of "first dashboard editing workflow"? Seems to me that these permissions would be the same as the create / edit dashboard config role

Yeah, I think you're right about that. That permission would cover it