Short answer: Start SaaS roles and permissions with a role-based model scoped to each customer organization (owner, admin, member, read-only), check every request against the organization first and the role second, and log every permission change. Add relationship or attribute rules when customers need per-record sharing, and SAML SSO with SCIM provisioning when an enterprise deal requires them. The right model depends on how your customers share data internally.
Key takeaways
- Organization first, role second: every query carries the organization ID, and a role only applies inside it.
- RBAC covers most early products: a short list of roles mapped to named permissions is easy to explain and audit.
- ReBAC fits sharing: Google's Zanzibar paper (USENIX ATC 2019) describes the relationship model behind access control in Drive, Calendar and YouTube; OpenFGA is an open-source CNCF project built on it.
- Enterprise buyers ask for SSO and SCIM: sign-in through their identity provider and automatic account removal when an employee leaves.
Three models: RBAC, ABAC and ReBAC
Role-based access control (RBAC) maps permissions to roles and roles to users. Attribute-based access control (ABAC), as defined in NIST SP 800-162, evaluates attributes of the user, resource, action and environment against a policy, such as "managers approve invoices up to a set amount in their region". Relationship-based access control (ReBAC) checks a chain: the user belongs to a team, the team can edit a folder, the folder contains the document.
| Model | Fits | Cost |
|---|---|---|
| RBAC | Admin panels, internal tools, early B2B products | Roles multiply with every exception |
| ABAC | Rules on amounts, regions or record status | Policies are harder to test and explain |
| ReBAC | Sharing, nested workspaces, folders | Needs a separate, synced authorization store |
Define permissions as named actions (invoice.approve, user.invite) and map roles to them, so a new role is a configuration change. This applies even to a custom CRM, where each rep sees only their own pipeline.
Multi-tenancy, invites and the user lifecycle
The most damaging permission bug in B2B SaaS is a leak between customer organizations. Filter every query by organization ID in one shared data-access layer or with row-level security, and run integration tests with two organizations. A user can hold a different role in each organization, so membership gets its own table (user, organization, role).
An invite carries the organization and the role, expires, and only the invited email address can accept it. The first screen a new member sees is part of app onboarding and user retention, so the default role should allow useful work on day one. Permission checks run on the server; hiding a button is cosmetic, as covered in mobile app security best practices.
