---
title: "Access control"
description: "The IAM actions and managed policies for managing EZGH SSO, and how IAM applies to directory users."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.ezghcloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access control

Managing EZGH SSO is an IAM decision: org-api checks every management request against the
caller's policies, like any other API. What happens inside the directory (who signs in, who is
assigned to what) is the directory's decision. See
[Directory decisions and IAM decisions](/sso#directory-decisions-and-iam-decisions).

## Managed policies

| Policy | Grants |
| --- | --- |
| `SsoFullAccess` | `sso.*`: manage the directory, its users and groups, email domains, custom domains, identity providers, directory SCIM tokens, applications, assignments and outbound provisioning. |
| `SsoReadOnlyAccess` | The `list` and `read` actions: view the directory, users and their sessions, groups, email domains, custom domains, identity providers, SCIM token metadata, applications, assignments, provisioning status and the catalog. Never a token or secret. |

Both also include `organizations.get`, `projects.list` and `projects.get`, like every product
policy. The platform's `ReadOnlyAccess` includes the same `list` and `read` actions. The root
user can do everything.

## Actions

All actions are on the directory or the resource named, in your organization.

| Action | Access level | Allows |
| --- | --- | --- |
| `sso.directories.get` | Read | View the directory |
| `sso.directories.create` | Write | Create the directory |
| `sso.directories.update` | Write | Change the alias, sign-in policy, branding and logo |
| `sso.directories.delete` | Write | Delete the directory with all of its users and groups |
| `sso.users.list` | List | List users |
| `sso.users.get` | Read | View a user and their groups |
| `sso.users.create` | Write | Create hosted users |
| `sso.users.update` | Write | Change a user's profile |
| `sso.users.delete` | Write | Delete a user |
| `sso.users.suspend` | Write | Suspend a user |
| `sso.users.reactivate` | Write | Reactivate a suspended user |
| `sso.users.resetFactors` | Write | Remove a user's password, TOTP and passkeys, and email them a link to enroll again |
| `sso.users.resendActivation` | Write | Send a pending user a new activation email |
| `sso.sessions.list` | List | View a user's sessions |
| `sso.sessions.revoke` | Write | Sign a user out of every session |
| `sso.groups.list` | List | List groups |
| `sso.groups.get` | Read | View a group and its members |
| `sso.groups.create` | Write | Create groups |
| `sso.groups.update` | Write | Change a group's name, description and tags |
| `sso.groups.delete` | Write | Delete a group |
| `sso.groups.addMembers` | Write | Add users to a group |
| `sso.groups.removeMembers` | Write | Remove users from a group |
| `sso.domains.list` | List | List email domains |
| `sso.domains.get` | Read | View an email domain and its verification |
| `sso.domains.create` | Write | Add an email domain |
| `sso.domains.verify` | Write | Check a domain's verification record now |
| `sso.domains.delete` | Write | Remove an email domain |
| `sso.customDomains.list` | List | List custom domains |
| `sso.customDomains.get` | Read | View a custom domain, its DNS records and certificate |
| `sso.customDomains.create` | Write | Add a custom domain |
| `sso.customDomains.verify` | Write | Check a custom domain's DNS records now |
| `sso.customDomains.delete` | Write | Remove a custom domain |
| `sso.identityProviders.list` | List | List identity providers |
| `sso.identityProviders.get` | Read | View an identity provider (never its client secret) |
| `sso.identityProviders.create` | Write | Add an identity provider |
| `sso.identityProviders.update` | Write | Change an identity provider's settings, domains and group mappings |
| `sso.identityProviders.delete` | Write | Remove an identity provider |
| `sso.identityProviders.refreshMetadata` | Write | Fetch an identity provider's metadata and keys now |
| `sso.scimTokens.list` | List | List directory SCIM tokens (never the tokens) |
| `sso.scimTokens.create` | Write | Create a directory SCIM token, shown once |
| `sso.scimTokens.delete` | Write | Delete a directory SCIM token |
| `sso.applications.list` | List | List applications |
| `sso.applications.get` | Read | View an application's settings (never a client secret) |
| `sso.applications.create` | Write | Create an application: an OIDC client, a SAML service provider or an EZGH app |
| `sso.applications.update` | Write | Change an application's settings |
| `sso.applications.delete` | Write | Delete an application, ending every grant and token it holds |
| `sso.applications.rotateSecret` | Write | Create (shown once) or delete a client secret |
| `sso.assignments.list` | List | List who is assigned to an application |
| `sso.assignments.update` | Write | Assign and unassign users and groups |
| `sso.provisioning.get` | Read | View an application's provisioning settings and status (never its bearer token) |
| `sso.provisioning.update` | Write | Change an application's provisioning settings and bearer token |
| `sso.provisioning.reconcile` | Write | Reconcile an application's provisioned users and groups now |
| `sso.catalog.list` | List | View the application catalog |

Errors follow the platform's rules: `401` without a valid credential, `403` when your policies
don't allow the action, and `404` for an organization you aren't in.

## IAM for directory users

Directory users never get access to manage EZGH Cloud as themselves. With
[console access](/sso/console-access), they can use the console as a bot that trusts them, with
exactly the bot's policies; the policies below don't apply there. Mapping a group or user to a bot
needs `bots.updateTrust` on the bot (in `IAMFullAccess`) and `sso.assignments.update`.

When an EZGH product accepts directory users, what they may do in it comes from policies attached
to the directory user, or to their directory groups, checked on every request:

- Only actions of products that accept directory users ever apply to them. Actions such as
  `organizations.*`, `projects.*`, `iam.*`, `sso.*` and `billing.*` never do, whatever policy is
  attached.
- A product's managed policy, such as MCP Central's, attaches unchanged; its platform actions
  simply don't apply.
- Group membership comes from the directory, live: adding someone to `engineering` gives them
  what's attached to `engineering` on their next request.

### Attach policies to directory users and groups

Policies attach to directory users and groups through the Organizations API, by the principal's
resource name (`ezgh:us-west-1:org_…:dir_…:usr_…` or `…:dgp_…`), and need `policies.attach`:

| Directory users | Directory groups |
| --- | --- |
| [ListSsoUserPolicies](/orgs-api/ssoPrincipals/ListSsoUserPolicies/) | [ListSsoGroupPolicies](/orgs-api/ssoPrincipals/ListSsoGroupPolicies/) |
| [AttachSsoUserPolicy](/orgs-api/ssoPrincipals/AttachSsoUserPolicy/) | [AttachSsoGroupPolicy](/orgs-api/ssoPrincipals/AttachSsoGroupPolicy/) |
| [DetachSsoUserPolicy](/orgs-api/ssoPrincipals/DetachSsoUserPolicy/) | [DetachSsoGroupPolicy](/orgs-api/ssoPrincipals/DetachSsoGroupPolicy/) |

A policy that grants nothing a directory user can use is refused (`400`). Until the first such
product, MCP Central, launches (see [EZGH apps and MCP clients](/sso/ezgh-apps)), that's every
policy. Deleting a directory user or group removes its attachments.

Source: https://docs.ezghcloud.com/sso/access-control/index.mdx