Role-Based Access Control [RBAC]
Last updated: June 12, 2026
Role-Based Access Control (RBAC) lets you define who should have access to which applications - and, optionally, with what role - through reusable policies instead of one-off, manual grants. Rather than tracking access in a spreadsheet or granting apps to people individually, you describe the rule once ("the Engineering team gets access to GitHub as a Developer") and YeshID keeps reality lined up with that rule.
RBAC is a great fit if you are trying to answer questions like "Who has access to this app, and why?" or "What should this person have, based on their role?" - without having to stitch the answer together from six different systems.
RBAC is available on the Business plan.
If you don't see RBAC under Access, talk to your YeshID contact about upgrading your plan.
What's included with RBAC
A single, reviewable definition of access. Each policy is a plain-language statement of who gets what, that you and your auditors can read at a glance.
Access tied to people and groups, not to individuals one at a time. Add someone to a group, and they inherit the access the relevant policies grant. Remove them, and it's taken away.
Optional automatic provisioning. A policy can simply authorize access, or it can actively provision accounts for everyone it covers (see Provisioning type).
Drift detection. YeshID continuously compares your policies to the access people actually have and flags the gaps - accounts that should exist but don't, accounts no one owns, and people with access who fall outside every policy.
One-click remediation. When YeshID finds drift, it can generate the workflow tasks needed to fix it (add the missing accounts, remove the extra ones) and route them to the right app admins.
Key terms
These are the core concepts you'll see in the YeshID RBAC interface. They build on each other, so it's worth reading them in order.
Term | What it means |
|---|---|
RBAC Policy | The top-level rule. A policy ties a set of people (Principals) to a set of applications they should be able to access. You give it a name, an optional description, and turn it on with the Active toggle. |
Principal | Who receives access. A principal can be an individual user or a whole group. When you add a group as a principal, every member of that group inherits the policy's access — and membership changes are picked up automatically. |
Owner | Who manages the policy. Owners can be users or groups, and every policy needs at least one. Owners are distinct from principals: owning a policy does not, by itself, grant you the access it describes. |
Application (Access) | What the policy grants access to. In the policy editor this lives under the Access tab — each entry is an application the principals should be able to reach. |
Role | An optional role within a granted application (for example, "Admin," "Member," or "Viewer"). If you don't pick a role, the policy grants standard access to the app. |
Provisioning type | How the policy behaves - either Lazy (authorize only) or Eager (authorize and automatically create accounts). See below. |
Access drift | The gap between what your policies say should be true and the access people currently have. YeshID surfaces drift so you can decide whether to fix the policy or fix the access. |
Remediation | The corrective action - usually an auto-generated workflow that creates or removes accounts - that brings actual access back in line with your policies. |
Provisioning Type
Each application you add to a policy has a provisioning type that controls how proactive YeshID is:
Type | Behavior |
|---|---|
Lazy | The policy authorizes access but doesn't create accounts on its own. Use this when the policy is about saying "these people are allowed to have this app" — for access reviews, audits, and request approvals — without immediately provisioning. |
Eager | The policy authorizes and provisions. YeshID will work to make sure everyone the policy covers actually has an account in the application, and will flag missing accounts as drift to remediate. Use this for access you want guaranteed, like the core tools every engineer should have on day one. |
RBAC Policy Example
A policy answers three questions:
Who? — the Principals (users and/or groups).
What? — the Applications under the Access tab, each with an optional Role.
How? — the Provisioning type (Lazy or Eager) for each application.
A worked example:
Policy: "Engineering — Core Tools"
Principals: the Engineering group
Access:
GitHub (Role: Developer, Eager)
Datadog (Role: Member, Eager)
Figma (Lazy)
Every member of Engineering will be provisioned a GitHub Developer account and a Datadog Member account automatically. They're also authorized for Figma, but YeshID won't create those accounts until someone requests one or the access drift is addressed. When a new engineer joins the Engineering group, they pick up all three automatically; when someone leaves the group, the policy stops covering them and the drift report flags the access to remove.
RBAC, Groups, and Provisioning
RBAC works alongside features you may already be using, and it helps to be clear on the boundaries:
Groups are collections of people. RBAC uses groups as principals, but a group on its own doesn't decide application access — a policy does. Groups answer "who's on this team"; RBAC answers "what does this team get."
SCIM + Custom API Integrations are how access is actually delivered to an application. RBAC decides that someone should have a GitHub account; the GitHub integration is what creates it.
Access requests let an individual ask for access on demand. RBAC and requests complement each other: a Lazy policy can define who's eligible to request an app, while Eager policies grant standing access up front.
Access Drift
Once policies are in place, YeshID continuously checks them against reality and reports any access drift (found within Security under menu.) The common drift situations:
Situation | What it means | Typical fix |
|---|---|---|
Missing access | Someone a policy covers doesn't have the account it should provision (Eager policies only). | Remediate to create the account. |
Unlinked account | An account exists in the application but isn't tied to any YeshID user. | Link it to the right person, or remove it. |
Over-provisioned | Someone has access to a restricted app but isn't covered by any policy. | Remove the access, or add them to (or create) a policy that should cover them. |
When you save changes to a policy, YeshID can preview the impact first and then generate remediation workflows to carry out the additions and removals — so you're never guessing what a policy change will do before it happens.
How RBAC works with Workflows
A key thing to understand: RBAC rarely changes access silently. Instead, it expresses changes as Workflows — the same task-and-approval engine YeshID uses for onboarding and offboarding. That means every grant or removal RBAC drives is visible, attributable, and (when you want it) reviewable before anything happens. RBAC decides what should change; Workflows are how the change gets carried out.
The tasks RBAC generates are routed to the relevant application administrators, and the most common ones are:
Add user to application — provision an account (with the policy's role, if one is set).
Remove user from application — revoke access that no longer matches any policy.
An account-mapping task when an application account exists but isn't linked to a person.
You decide whether these run immediately or are staged for review first.
When RBAC creates workflow activity
Moment | What RBAC does |
|---|---|
A policy is created or changed | When you save, YeshID previews the resulting drift and lets you choose Publish only or Publish & run/stage workflow. Choosing to run generates a workflow with the add/remove tasks needed to bring access in line with the new policy. |
A new hire is onboarded | An onboarding template can include the Apply RBAC policy task. When the new hire is onboarded, it evaluates which policies cover them and automatically kicks off tasks to provision the apps their Eager policies grant. |
Group membership changes | When someone joins or leaves a group (for example, via an HR/People source sync), RBAC re-evaluates the affected people and can automatically open a workflow to add or remove access so it matches their new group membership. |
You remediate drift | From a policy or from an application's drift view, you can trigger a workflow on demand to fix any mismatches RBAC has detected. |
A user is deactivated | RBAC automatically removes that person from the policies they were part of, so they stop being counted as a principal. (Removing their actual application accounts is handled by your normal offboarding workflow.) |
Using the "Apply RBAC policy" task in onboarding
To have RBAC provision access automatically on day one, add the Apply RBAC policy task to your onboarding workflow template. When the workflow runs for a new hire, the task:
Works out which RBAC policies cover that person (directly or through their groups).
Looks at the Eager applications those policies grant.
Creates Add user to application tasks for anything they don't already have, so the right accounts get provisioned without anyone building the list by hand.
Because it's automated, there's nothing to click — but the resulting access still shows up as workflow tasks you can see and audit. (Note: this task is intended for onboarding workflows, and applies the policies' Eager grants; Lazy grants stay request-based.)
Getting started
In YeshID, go to Access > RBAC.
Select New RBAC Policy, give it a clear name (e.g. "Sales — CRM Access"), and assign at least one Owner.
On the Principals tab, add the users or groups the policy should cover. Prefer groups where you can — they keep the policy self-maintaining as people join and leave.
On the Access tab, add the applications. For each one, optionally choose a Role and set the Provisioning type (Lazy or Eager).
Set the policy Active, then review the change summary. If YeshID detects drift, let it generate the remediation workflows to bring access into line.
Revisit the policy whenever the team's needs change — RBAC is meant to be a living definition of access, not a one-time setup!
Tips and good habits
Start with groups, not individuals. A policy built on groups maintains itself; a policy built on named people needs editing every time the team changes.
Use Lazy first when you're unsure. Authorizing access without auto-provisioning lets you see who a policy covers before YeshID starts creating accounts.
Name policies for the rule, not the app. "Engineering — Core Tools" tells a reviewer the intent; "GitHub policy" doesn't.
Treat drift as a signal, not just a chore. Recurring overprovisioning often means a policy is missing or a group is out of date — fixing the cause beats repeatedly remediating the symptom.