On this page
What RBAC is
Role-based access control names a set of permissions, calls it a role, and gives people roles instead of individual grants. It is the model most applications arrive at eventually, because a per-person list of permissions does not survive a reorganization.
In SenseCrypt the model lives in the identity provider. Roles are defined once and resolved at sign-in, so every application behind SenseCrypt reads the same answer instead of maintaining its own copy.
A role is a named set of permissions
Change what a role allows in one place and every user holding it changes with it. That is the entire reason the model exists.
Resolved at sign-in, emitted in the token
SenseCrypt computes the user's roles and permissions during authentication and writes them into the token or the SAML assertion your application receives.
How RBAC works
You define roles, then assign them to users or to groups your directory provisions. At sign-in SenseCrypt resolves what the user holds and emits it as a claim. Your application reads that claim and grants or denies each request.
Two checks happen inside SenseCrypt itself, and it is worth knowing exactly which two.
A default-closed group gate at sign-in
A user with no granted group gets no token at all. Access starts closed and is opened by assignment, never the other way round.
Capability checks on the admin console
Every administrative route in the SenseCrypt console checks the operator's capabilities, so an administrator cannot reach a function they were not granted.
Everything else is your application's decision
The claim tells your application what the user holds. What that permits inside your product is enforced by your product.
Where enforcement actually happens
Vendors gloss over this, so here it is plainly. SenseCrypt is the source of the answer, not the enforcer of it. We compute the roles and permissions and put them in the token. Your application is what stands between a request and a record.
That split is normal for a standards identity provider. Design around it, rather than discovering it during an audit.
One place to change a role
Update the role in SenseCrypt and every application reading the claim sees the new answer at the next sign-in. You are not editing permissions in five products by hand.
Roles do not cross tenants
Role definitions and assignments are scoped to a tenant. One customer's administrator cannot grant anything inside another customer's directory.
Administrative changes are logged
The audit log records console administration, including who changed a role and when, per tenant.
How RBAC fits your stack
Roles ride on the protocol you already use. An OIDC application reads them from the token, and a SAML service provider reads them from the assertion. Nothing about the delivery is proprietary.
The sign-in that produces them is the passwordless one, so the user proves presence with a live face on a bound device before any role is emitted.
Same roles across OIDC and SAML
One definition feeds both protocols, so a mixed estate does not end up with two access models that slowly drift apart.
Directory groups drive assignment
SCIM provisioning carries group membership in, which is what most organizations already use to decide who should hold what.
Start on the 30-day trial
No card is needed. List price is one dollar per user per month, with a 20-seat minimum.
Frequently asked questions
Does SenseCrypt support RBAC?
Yes. SenseCrypt gives role-based access control. You assign roles to users. Each role grants a set of permissions.
How does RBAC work with face login?
The user signs in by face login. SenseCrypt puts the user's roles and permissions in the token. Your app reads the claim and grants or denies access.
Does RBAC work across tenants?
Yes. Multi-tenant isolation keeps each tenant separate. Roles stay within their own tenant.
Related