Identity & SSO

Admin guide

Greenlight authenticates every user through your identity provider. Today, sign-in uses OpenID Connect with Entra ID, Okta, or Google Workspace. SAML 2.0 and SCIM provisioning are coming soon.

This page covers the per-IdP setup. The conceptual model — workload identity, agent identity, RBAC — is in Identity & access.

Protocol support

Use OIDC for current installs.

Protocol	Notes
OpenID Connect	Supported today for Entra ID, Okta, and Google Workspace.
SAML 2.0	Coming soon for IdPs or enterprise standards that require SAML.
SCIM 2.0	Coming soon for automatic user and group provisioning.

Wire it up

Entra ID

1. In Entra ID, create an Enterprise application for Greenlight. Pick “Integrate any other application you don’t find in the gallery.”
2. Configure OIDC by registering Greenlight as a confidential client. Add the Greenlight redirect URL the install wizard provides.
3. Add the groups you want mapped to Greenlight roles as claims on the token.
4. Grant the Microsoft Graph permissions the install wizard requests for user and group lookup.
5. Verify the group claims Greenlight receives before mapping groups to roles.

Okta

1. In Okta, create an OIDC Web Application.
2. Set the sign-in redirect URI from Greenlight’s first-run wizard.
3. Add the groups claim to the ID token.
4. Assign the groups that should have Greenlight access.
5. Verify the group claims Greenlight receives before mapping groups to roles.

Google Workspace

1. Configure Greenlight as an OIDC client in Google Cloud for the Workspace domain.
2. Add the redirect URI from Greenlight’s first-run wizard.
3. Grant the scopes the install wizard requests for sign-in and group lookup.
4. Verify the group claims Greenlight receives before mapping groups to roles.

Group-to-role mapping

Once SSO is working, the Users, groups, RBAC page in the dashboard captures the mapping from IdP groups to Greenlight roles. Mappings are stored as rows, audited on every change, and applied at the next session start for any affected user.

Mappings can be 1:1 (one group = one role), many-to-one (multiple groups all grant the same role), or one-to-many (one group grants several roles for users on cross-functional teams). The mapping table lives entirely in the dashboard; no IdP-side schema change is needed.

Coming soon: SAML and SCIM

SAML 2.0 and SCIM 2.0 are coming soon. When they ship, they will use the same session cookie, /auth/check contract, RBAC mapping, and audit model as OIDC.

Verify SSO

The dashboard’s installation health page includes an “SSO round-trip” probe that signs into the IdP and back to Greenlight, then verifies the resulting session has the expected claims. Run it after every IdP-side change.

Tip

If a user complains they can’t sign in but should be able to, the audit log records every failed SSO attempt with the reason. Most “I can’t sign in” tickets are resolvable from the audit log alone.

Next

Users, groups, RBAC The mapping from IdP groups to Greenlight roles.

Identity & access The concept page covering workload and agent identity.

Manage integrations The next setup step after SSO.