Govern is the identity provider for the Neural Inverse apps and the authorisation service for everything it governs. Identity covers who someone is and how they prove it; access covers what they may do once signed in. This page maps the topics and where each is configured.
Where to configure it
Two console services hold identity and access:
| Console service | What it holds |
|---|---|
| Identity Center | Workforce sign-in: SAML and OpenID Connect connections, verified domains, SSO enforcement, group mappings, permission sets, social sign-in, SCIM provisioning and LDAP directory sync. |
| Access | People, teams or groups, roles, API keys, group permissions, JIT and break-glass, and compliance overrides. |
Some page names depend on how Govern is run. A self-hosted installation says Members, Teams, API keys and Audit log; the hosted service says Users, Groups, Access keys and Audit trail. The pages are the same.
Sign-in
| Topic | Page |
|---|---|
| Passwords, password policy, TOTP, recovery codes, passkeys, sessions and step-up | Sign-in, MFA and passkeys |
| Single sign-on with SAML 2.0 (Microsoft Entra ID, Okta and others) | Single sign-on with SAML |
| Single sign-on with OpenID Connect | Single sign-on with OIDC |
| Verified domains, SSO-only sign-in and break-glass | Domains and SSO enforcement |
| Provisioning and deprovisioning from your identity provider | Directory sync with SCIM |
| Mapping identity provider groups to roles | Permission sets and group mappings |
| LDAP and Active Directory | LDAP directory sync |
Access
| Topic | Page |
|---|---|
| Account roles, resource roles, bindings and the permission grammar | Roles and permissions |
| Deny policies, permission ceilings, delegation and separation of duties | Access guardrails |
| Eligible roles, activations, break-glass and resource access requests | Just-in-time access |
| Periodic certification of who holds what | Access reviews |
| Keys for scripts, CI and non-human principals | API keys and service accounts |
How a request is decided
Every route Govern serves declares what it needs: no credential, any signed-in caller, or a permission on a node of the directory. The server refuses to start if a route has no declaration, and a request to an undeclared route is denied.
For a permission check, Govern evaluates in this order and stops at the first step that decides:
- The permission must exist in the catalog. An unknown permission is denied.
- The node must belong to the caller's organisation.
- The caller must not be disabled in the organisation.
- Deny policies on the node or its ancestors. A deny whose condition cannot be evaluated still applies.
- Permission ceilings on the node or its ancestors.
- Role bindings on the node or its ancestors, for the person, their groups or the service account.
- Separation-of-duties rules.
An API key holds a permission only when both its own scopes and the principal it acts for hold it. A check that fails for an internal reason answers an error instead of falling back to a permission list.
Every change to roles, bindings, policies, settings, activations and reviews is written to the audit log in the same transaction as the change. See Audit log.
Maturity
Some identity features in the source are not ready and are not documented as available:
- Magic-link sign-in is partial: the link does not issue a session.
- The general step-up authentication package is not mounted. Specific flows ask for a fresh second factor themselves; see Sign-in, MFA and passkeys.
- Personal access tokens and mTLS client certificate routes are not mounted.
- Self-service requests for IDE and tool access (
/api/v1/me/access-requests) are partial: an approval is recorded but grants nothing on the device yet. Resource access requests, described on Just-in-time access, work. - LDAP is partial; see LDAP directory sync.