---
title: "Permission sets and group mappings"
---

# Permission sets and group mappings

Turn identity provider groups and SCIM groups into Neural Inverse Govern roles with permission sets, account assignments, group mappings and just-in-time provisioning rules.

Identity Center maps people from your identity provider to Govern roles, so access follows group membership in the identity provider instead of being granted by hand. The console pages are **Identity Center > Permission sets** and **Identity Center > Group mappings**.

## Concepts

| Term | Meaning |
|---|---|
| Permission set | A named account role with a session length. |
| Account assignment | A permission set given to a user or group in one account of the organisation. |
| Group mapping | A rule on a connection: a SCIM group or a group value in the identity provider's claims gives a permission set, an account role or a project role. |
| JIT rules | Whether a person who signs in through the connection for the first time gets a login, and with what default permission set. |

Bindings created by Identity Center are marked as managed by it. They cannot be changed by hand (`managed_by_identity_center`), and they are reconciled at every sign-in through a connection and every SCIM change.

## Create a permission set

`CreatePermissionSet` (`sso.permissionsets:createpermissionset`):

| Field | Rule |
|---|---|
| `Name` | 1 to 32 letters, digits and `+=,.@_-` |
| `Description` | At most 700 characters |
| `SessionDuration` | ISO 8601, `PT1H` to `PT12H` |
| `AccountRole` | `ADMIN`, `MEMBER`, `SECURITY_COMPLIANCE`, `BILLING`, `READ_ONLY_ALL`, or `CUSTOMER` with `CustomerRoleName` |

Owner can never be granted through a permission set (`400 OWNER_NOT_GRANTABLE`). An organisation can have up to 100 permission sets. Changing a permission set provisions it again in every account it is assigned in; `DescribePermissionSetProvisioningStatus` shows the state per account, and a failed account is retried every 10 minutes.

## Map groups

`CreateGroupMapping` (`sso.mappings:creategroupmapping`) takes a connection, a source and a target:

| Source | Meaning |
|---|---|
| `scim_group:<group ID>` | Members of a group pushed by SCIM |
| `claim:<group value>` | A value of the groups attribute or claim at sign-in |

| Target `Type` | Gives |
|---|---|
| `PERMISSION_SET` | A permission set in the listed `AccountIds` |
| `ACCOUNT_ROLE` | An account role (or a custom role with `CustomerRoleName`) in one account |
| `PROJECT_ROLE` | `USER`, `VIEWER`, `EDITOR` or `MANAGER` on one project |

A connection can have up to 500 mappings. `ListGroupMappings` also returns a preview: the groups of the connection's last passing test sign-in and the mappings they would apply. Run a test sign-in from the connection page to see the effect before you rely on a mapping.

## Just-in-time provisioning

`PutJitRules` (`sso.mappings:putjitrules`) sets, per connection, whether a first sign-in creates a login (`Enabled`), whether this also happens while SCIM is active (`JitWithScim`), and an optional default permission set and account (`DefaultPermissionSetArn` and `DefaultAccountId`, both or neither). JIT accepts only company addresses of verified domains pointed at the connection; see [Domains and SSO enforcement](https://neuralinverse.com/docs/govern/sso-enforcement/).

## Actions and permissions

| Action | Permission |
|---|---|
| `CreatePermissionSet`, `UpdatePermissionSet`, `DeletePermissionSet`, `ListPermissionSets`, `DescribePermissionSetProvisioningStatus` | `sso.permissionsets:<action in lower case>` |
| `CreateAccountAssignment`, `DeleteAccountAssignment`, `ListAccountAssignments` | `sso.assignments:<action in lower case>` |
| `CreateGroupMapping`, `DeleteGroupMapping`, `ListGroupMappings`, `PutJitRules`, `GetJitRules` | `sso.mappings:<action in lower case>` |

All actions are `POST /api/v1/svc/sso/<Action>`, and every change is audited as `sso:<Action>`. A permission set that an assignment, mapping or JIT default still names cannot be deleted (`409 PERMISSION_SET_IN_USE`).