Role-based access control design for business and healthcare applications
Most permission problems start as a quick role added for one customer, then another. Agnotic Technologies designs and builds the roles, permission checks and admin screens for your application, so access stays explainable as the product and its customers grow.
Last reviewed by the Agnotic Technologies engineering team
How should you design role-based access control for an application?
Role-based access control (RBAC) design starts from job functions: group permissions into roles, assign roles to users and never grant permissions to users directly. Where a role cannot decide alone, such as record ownership, care team membership or tenant, add an attribute or relationship check. Agnotic Technologies builds the permission service, admin screens and audit trail.
What goes wrong with roles and permissions?
Access control rarely fails on day one. It drifts as each new customer, team and feature adds an exception.
Role explosion
A new role is created for every customer request, until nobody can say what the 40th role allows or why it exists.
Permissions granted straight to users
A one-off grant to fix a ticket bypasses the role model and stays forever, invisible in any role report.
Checks only in the user interface
Buttons are hidden for the wrong roles, but the API behind them answers anyone with a valid session.
Questions a role cannot answer
Should this clinician see this patient? Should this manager approve their own expense? A role name alone does not know.
Tenant boundaries in application code
In a multi-tenant product, one missed tenant filter in one query shows a customer another customer's records.
Access that never gets reviewed
People change jobs or leave, and their roles stay. Nobody can produce a list of who can do what for an auditor.
What do we build for access control?
Agnotic Technologies builds access control into your product to your requirements, whether it is a new application or one whose roles have grown out of hand. These are the parts we typically build.
Permission catalogue
Every action the product allows, named once as a permission, so roles are built from a known list instead of feature flags.
Central policy check in the API layer
One authorization service or library that every endpoint calls, denying by default and checking on every request.
Attribute and relationship rules
Policies for ownership, care team or account membership, location and data sensitivity, evaluated beside the role check.
Tenant-scoped roles
Roles that customers manage inside their own tenant, kept apart from the platform roles your own staff hold.
Admin console for roles
Screens where an authorized admin assigns roles, sees what each role allows and compares two users' access.
Separation of duties rules
Conflicting roles that cannot be held together, and approvals that cannot be made by the person who requested them.
Break-glass access
Emergency access with a stated reason, a time limit, an alert and a review queue afterwards.
Access reviews and revocation
Scheduled reviews where managers confirm each person's roles, and automatic removal when someone leaves.
How do you design roles that do not multiply?
Role design is a modelling exercise before it is a coding one. We run it in this order.
List the actions the product allows, as verbs on objects: view a claim, approve a refund, export a report. This becomes the permission catalogue.
Interview the teams that use the product and write down the job functions they actually do, not their job titles.
Build one role per job function from the catalogue, and give each role the fewest permissions that let it do that job.
Move every rule that depends on the record, such as owner, team, tenant or sensitivity, out of the role and into an attribute or relationship check.
Add hierarchy only where a senior role truly includes a junior one, and write down the pairs of roles one person must not hold.
Set a rule for new requests: a customer need becomes a permission or a policy first, and a new role only when a new job function exists.
Which access model fits each access need?
RBAC answers who does which job. Other needs are better answered by attributes or by relationships, and most products end up with a mix.
| Access need | Example | Model that fits | Why |
|---|---|---|---|
| Fixed job functions | Billing clerk, nurse, support agent | RBAC | The job decides the actions, whatever the record |
| Record ownership | A user edits only drafts they created | Relationship check | The answer depends on who created the record |
| Care team or account relationship | A clinician opens only patients on their care team | Relationship-based (ReBAC) | Access follows a link between the user and the record |
| Location, time or device limits | Payroll changes only from the office network in working hours | Attribute-based (ABAC) | The environment decides, not the job |
| Data sensitivity labels | Behavioral health notes or restricted employee records | ABAC on top of RBAC | The same role sees ordinary records but not labelled ones |
| Multi-tenant customers | A customer admin manages users in their own company only | Tenant-scoped RBAC | Roles hold only inside the tenant that granted them |
| Emergency access | An on-call clinician needs a chart outside their care team | Break-glass override | Access is allowed, then reviewed, instead of being refused |
What does the standard RBAC model include?
The NIST RBAC model, later adopted as the ANSI/INCITS 359 standard, gives the vocabulary most teams use. Each part maps to a design decision.
Core RBAC
Users are assigned roles, roles are assigned permissions, and a session activates the roles a user needs. Users never hold permissions directly.
Role hierarchies
A senior role inherits a junior role's permissions. Useful for supervisor and staff pairs; harmful when used to avoid listing permissions.
Static separation of duty
Pairs of roles one person may never hold together, such as the role that creates a vendor and the role that pays it.
Dynamic separation of duty
Roles one person may hold but not activate in the same session or on the same transaction, such as requesting and approving one refund.
How should roles work in a multi-tenant product?
Keep two layers apart. Platform roles are for your own staff, such as support and operations. Tenant roles are for customer users and hold only inside the tenant that granted them.
Put the tenant in every permission check and in every data query, enforced in one shared layer rather than in each feature. A support engineer who needs to see a customer's data should go through an audited, time-limited grant, not a permanent platform role.
Let customer admins assign roles from a list you control, and decide early whether they may define their own roles. Custom roles are a common customer request and a common source of role explosion. Our SaaS consulting work starts with this decision.
What do healthcare applications add?
The HIPAA Security Rule requires unique user identification and an emergency access procedure for systems that hold ePHI. In practice that means no shared logins, and a break-glass path that lets a clinician reach a record in an emergency.
Break-glass access should ask for a reason, last for a limited time, alert a reviewer and land in a review queue. Every use is written to the audit trail; see audit logging requirements for what each record holds.
Access reviews belong in the product too. The Security Rule asks covered entities and business associates to establish, document, review and modify each user's right of access, which is far easier when the product can list every user's roles on demand. For the wider control set, see healthcare software security and privacy.
Where do access control designs fail?
These are the failure points we look for first when we review an existing permission model.
- Role explosion: more roles than job functions, many with one user each.
- Direct grants: permissions attached to users outside any role.
- UI-only checks: hidden buttons with open API endpoints behind them.
- Missing object checks: the role allows viewing invoices, and the API returns any invoice ID it is given.
- Tenant filters added by hand in each query instead of one enforced layer.
- Break-glass access with no reason, no expiry and no review.
- No access review, so leavers and movers keep their roles.
- Admin roles that can grant themselves more access without a second approver.
Which standards and rules shape access control design?
Each fact is from the primary source: NIST, OWASP or the eCFR text of the HIPAA Security Rule.
The NIST model for role-based access control was adopted as American National Standard ANSI/INCITS 359-2004 on 11 February 2004 and revised as INCITS 359-2012.
Source: NIST CSRC, Role Based Access Control projectNIST SP 800-162 defines attribute-based access control as a method where authorization is decided by evaluating attributes of the subject, the object, the requested operations and, in some cases, environment conditions against policy.
Source: NIST SP 800-162 (CSRC)OWASP's Authorization Cheat Sheet recommends enforcing least privilege, denying by default and validating permissions on every request, and warns that RBAC can lead to role explosion when a system defines too many roles.
Source: OWASP Authorization Cheat SheetThe HIPAA Security Rule access control standard requires unique user identification and an emergency access procedure for systems that maintain ePHI (45 CFR 164.312(a)).
Source: 45 CFR 164.312 (eCFR)Under 45 CFR 164.308(a)(4)(ii)(C), covered entities and business associates implement policies and procedures that establish, document, review and modify a user's right of access.
Source: 45 CFR 164.308 (eCFR)
Trusted by global innovators
Where should you go next?
- Healthcare software security and privacyThreat models, encryption and the security tests a health system review expects.
- Zero trust architectureIdentity, device and network controls that check every request.
- Application security consultingDesign review, testing and fixes for application security gaps.
- SaaS consultingTenancy, packaging and platform decisions for SaaS products.
- Audit logging requirementsWhat a regulated application records in its audit trail, and for how long.
- Identity and access management servicesSign-in, MFA, single sign-on and authorization built into your own applications.