Users, groups, RBAC
Admin guide
Greenlight’s access control is group-based. You map IdP groups to one of three Greenlight roles in the dashboard. Today, IT manages the Greenlight-side user and group records manually; SCIM provisioning is coming soon.
The role definitions are in Governance & policy. This page covers the IT-side workflow.
The three roles
| Role | Maps to typical IdP group |
|---|---|
| Builder | Everyone who should be able to build apps with their agent — usually a broad group like All Engineering or Greenlight Users. |
| Admin | The day-to-day IT operations team that manages integrations, reviews proposals, runs the kill switch. |
| Org Owner | The small group (often 1–3 people) who installed Greenlight and own its long-term configuration. |
App ownership is not a role and isn’t mapped from IdP. A Builder who creates an app automatically owns it; that user can promote co-owners from the app’s detail page.
The mapping table
The dashboard’s Users, groups, RBAC page shows two views.
Group → role is the source of truth. Each row maps one IdP group id to one Greenlight role. Multiple rows for the same group are fine — they grant the union of the named roles.
| IdP group | Greenlight role |
|---|---|
okta-greenlight-owners | org_owner |
okta-it-greenlight-admins | admin |
okta-engineering | builder |
okta-data-team | builder |
Role → user is a derived view that shows who currently holds each role. Useful for compliance reviews and for sanity-checking after a group rename.
Adding a mapping
The wizard is two fields and a save: pick or enter the IdP group, pick the role from the dropdown, save. The mapping is audited and effective at the next session for users in the group.
Mappings take effect immediately. To stage a change, create the mapping with a temporary group your test users are in, verify, then move users into the real group.
Removing a mapping
Removing a mapping is the same workflow. Users who held the role only through that mapping lose it at the next session. Users who held it through other mappings retain it.
The audit log captures the actor, the group, the role, and the time. Compliance reviews that ask “how did user X get role Y” can be answered from the audit log without reconstructing IdP history.
App ownership
When a user creates an app, they automatically become its owner. Ownership gives them:
- Edit access to the app’s environment variables.
- The ability to request new integrations for the app.
- Edit access to the app’s app-scope Knowledge.
- The ability to suspend or restore the app (but not kill it — that’s an Admin action).
- The ability to promote other Builders to co-owners of the app.
Ownership is per-app, not a global role. A Builder who owns three apps can manage those three apps but cannot do anything an Admin can do.
A common mapping pattern
For a typical mid-size organization rolling Greenlight out for the first time:
| IdP group | Role | Reasoning |
|---|---|---|
| Greenlight Owners (1–3 people) | org_owner | The install owners and long-term operators. |
| IT Operations | admin | The team that handles integration requests, Knowledge curation, and incidents. |
| All Engineering / All Data / etc. | builder | The default role for everyone who might build with an agent. |
Three rows of mapping cover almost every install. Keep it simple — additional mappings rarely add value and they complicate compliance reviews.