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

# Create your RBAC Policy

> Use Role-Based Access Control (RBAC) to manage access to specific resources

export const rbac = "Role-Based Access Control: An authorization model that manages access to resources within your application based on user roles.";

Stytch's <Tooltip tip={rbac}>RBAC</Tooltip> model streamlines the management and enforcement of permissions with a flexible interface that's designed for a multi-tenant auth system.

<Columns cols={3}>
  <Card title="API Reference" icon="code" href="/api-reference/b2b/api/rbac/get-policy">
    Use the RBAC API to check permissions on your backend.
  </Card>

  <Card title="Frontend SDKs" href="/api-reference/b2b/frontend-sdks/react/hooks/use-stytch-is-authorized" icon="compass">
    Use the RBAC SDKs to gate UI based on permissions.
  </Card>

  <Card title="RBAC Dashboard" href="https://stytch.com/dashboard/rbac" icon="cloud-check">
    Manage your RBAC policy in the Stytch Dashboard.
  </Card>
</Columns>

## The RBAC Policy

An RBAC policy is a governing document that stores all access controls. It is the canonical source for all RBAC authorizations within a Stytch Project, made up of three core concepts:

* **Resources**: an abstract entity that your application interacts with
  * Examples: `documents`, `images`, `users`
* **Actions**: the specific operations that can be performed on a resource
  * Examples: `create`, `read`, `update`, `delete`
* **Roles**: a named collection of permissions that can be assigned to a member
  * Examples: `admin`, `editor`, `viewer`

The relationship between these three concepts is the foundation for Stytch's RBAC permissioning model.

### Resources

A [Resource](/api-reference/b2b/api/rbac/resource-object) represents an entity that your application interacts with. It is identified by `resource_id`, a unique, user-inputted string that allows you to freely name a Resource after almost anything.

Typically, Resources are modeled after data objects your users of your application create or manage. Such as `documents`, `images`, `invoices`, `products`, `employees`, or `credit-cards`.

### Actions

Resources are associated with a specific list of [Actions](/api-reference/b2b/api/rbac/resource-object#param-actions) that can be performed on them.

Typically, these actions are standard CRUD operations like `create`, `read`, `update`, and `delete`. However, you can also define more application-specific actions like `share`, `invite`, `block`, and `export`.

### Permissions

A permission is a combination of a Resource and an Action.  For example, the permission to `read` a `document` or to `create` an `employee`.

### Roles

A [Role](/api-reference/b2b/api/rbac/role-object) is a named collection of permissions. It is identified by `role_id`, a unique, user-inputted string that allows you to name a Role after the persona it represents.

For example, you might create an `admin` role with the following permissions:

* `read: employees`
* `create: employees`
* `update: employees`
* `delete: employees`

(Note: you could also use a `*` wildcard to grant a Role permission to use all possible actions related to a Resource.)

And a `viewer` role with the following permissions:

* `create: employees`
* `read: employees`

## Putting it all together

Create as many **Resources**, **Actions**, and **Roles** as your application needs. The more granular you can make your permissions, the more control you have over who can do what in your application.

To get started:

1. Configure your RBAC policy in the [Stytch Dashboard](https://stytch.com/dashboard/rbac) or using the [Programmatic Workspace Actions API](/api-reference/pwa/api/v3/rbac/get-rbac-policy).
2. Grant permissions by [assigning Roles to Members](/multi-tenant-auth/enterprise-ready/rbac/assigning-roles-to-members)
3. Use your RBAC policy to [gate access in your application](/multi-tenant-auth/enterprise-ready/rbac/enforcing-permissions).

## Default Roles and Resources

### Default Resources

Within your RBAC Policies, you'll find the following five default Resources, prefixed with `stytch.`, that represent core entities in a Stytch Project:

* `stytch.self`: access controls for the logged-in user's Member.
* `stytch.organization`: access controls for the Organization.
* `stytch.member`: access controls for all Members in the Organization.
* `stytch.sso`: access controls for SSO Connections.
* `stytch.scim`: access controls for SCIM Connections.

You can view the full list of Actions associated with each Stytch Resource in your [Stytch Dashboard](https://stytch.com/dashboard/rbac).

### Default Roles

To manage the default Resources, Stytch provides two default Roles for your convenience:

* **`stytch_member`: the base Role that's automatically assigned to all Members.** By default, it contains all `stytch.self` permissions, enabling permissions like updating your own name. It is automatically assigned to all Members, and cannot be removed.
* **`stytch_admin`: a Role that's automatically assigned to the Member that creates a new Organization.** By default, it includes all permissions for the `stytch.organization`, `stytch.member`, and `stytch.sso` resources.

These default roles cannot be deleted, but you can edit their permissions to suit the needs of your Project. For example, if you wanted to create your own `enterprise_admin` role as the *only* role that can manage SSO connections, you could remove the `stytch.sso` permissions from the `stytch_admin` Role.