Role-Based Access Control [RBAC]

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 (on applications you mark Monitored by RBAC) people with access who fall outside every policy.

• Enforcement, per application. Mark an application Monitored by RBAC and its policies become authoritative: nobody outside them can request it, and any access outside them is reported.

• 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 people.

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.

Provisioning Type

Each application you add to a policy has a provisioning type that controls how proactive YeshID is:

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. When a policy already covers someone, their request is approved automatically — and if the app is marked Monitored by RBAC, people no policy covers can't request it at all.

Monitored by RBAC

By default, a policy is additive: it describes access people should have, and YeshID works to deliver it. It says nothing about access people shouldn't have. So if someone was granted an app by hand last year, or kept it after changing teams, your policies won't object — because no policy claims that app is theirs to lose.

Monitored by RBAC is the setting that closes that loop. Turning it on for an application tells YeshID: for this app, the policies are the whole story. Anyone holding access who isn't covered by an enabled policy becomes an exception YeshID reports, and anyone not covered can no longer request it.

This is what turns RBAC from a provisioning convenience into an enforceable control. It's set per application, so you can enforce your sensitive systems while leaving low-risk tools open.

Where to find it

Go to Access > Applications, open the application, and select the Settings tab. Two related rows sit there:

• Monitored by RBAC — the checkbox itself. It saves as soon as you tick it.

• RBAC Policies — the policies currently linked to this app, shown as chips (green = Enabled, grey = Disabled). Select Manage to link or unlink policies without leaving the page.

Both rows appear only if RBAC is included in your plan.

What changes when you turn it on

Two details worth knowing:

• Auto-approval isn't exclusive to monitored apps. Whenever an enabled policy covers someone for an app, their request skips approval — monitored or not. What monitoring adds is the refusal for everyone else.

• A role mismatch is not a refusal. If a policy covers someone for the app but pins a specific Role, and they request a different role, the request goes through your normal approval tasks. It's neither auto-approved nor refused.

Enable your policies first

Turning on Monitored by RBAC before any enabled policy covers the app is the one sequence to avoid. With the setting on and no policy to match against, YeshID has nothing to compare access to, so:

• every existing account on the app is reported as Over-provisioned, and

• every new request for the app is refused.

Link and enable the policies first, confirm the drift report looks the way you expect, and then tick the box.

Deactivated people still count

Over-provisioned checks deliberately ignore whether a person is still active. Someone deactivated in YeshID who continues to hold an account on a monitored app is exactly the finding you want, and nothing else surfaces it — the account is still mapped to a person, so it won't show up as an unlinked account either.

Missing-access drift works the other way round: it only considers active people, so someone mid-onboarding or already offboarded doesn't generate noise.

Accounts with no person attached are never proposed for removal. They surface as Unlinked account instead, so you decide who owns them before anything gets revoked.

Access Drift

Once policies are in place, YeshID continuously checks them against reality and reports any access drift, found under Security > Access Drift. The common drift situations:

Only two of these three are reported for every application. Missing access and Unlinked account apply everywhere, but Over-provisioned findings appear only on applications you've marked Monitored by RBAC — that setting is what tells YeshID your policies are the complete picture for that app. If you're expecting to see extra access flagged and nothing shows up, check that setting first.

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 most common tasks RBAC generates 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. Generated for applications marked Monitored by RBAC, since that's where extra access is treated as drift.

• 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

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.

• If this application's policies should be authoritative — no access outside them — open the application's Settings tab and tick Monitored by RBAC. Do this once the policy is enabled, not before.

• 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.

• Reach for Monitored by RBAC once a policy has settled. A policy on its own describes the access you intend; monitoring makes it the only access. Turn it on after you've confirmed the policy covers the right people, and let the drift report be your check.

• 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 over-provisioning often means a policy is missing or a group is out of date — fixing the cause beats repeatedly remediating the symptom.