[Programadores]

Role-Based Access Control

Access control that works in a spreadsheet often fails in production. When organisations grow, roles multiply, permissions accumulate, and nobody is quite sure what any given user can actually do. The RBAC module…

Categoria: ManagementÚltima Atualização:
managementcompliance

Overview#

Access control that works in a spreadsheet often fails in production. When organisations grow, roles multiply, permissions accumulate, and nobody is quite sure what any given user can actually do. The RBAC module provides the structure to manage that complexity: a 13-role hierarchy with defined permission sets, visual inheritance tools, separation of duties enforcement, and automated access reviews that keep the model clean over time.

By default, every user in the system has zero access until a role is provisioned. That zero-privilege default, combined with RBAC, ensures access is always deliberate and auditable rather than accumulated by default.

Key Features#

  • Role Hierarchy and Inheritance: Define roles in a parent-child hierarchy where child roles automatically inherit parent permissions. Additive inheritance, permission overrides, and multiple inheritance support complex organisational structures. Visual hierarchy tools show permission flow and impact analysis for role changes.

  • Comprehensive 13-Role Catalog: A fully enumerated role-permission catalog defines authoritative permission sets for all platform roles: guest (rank 5), viewer (rank 10), read_only (rank 15), user (rank 20), content_editor (rank 30), analyst (rank 40), manager (rank 50), admin (rank 60), tenant_admin (rank 70), si_admin (rank 80), knogin_admin (rank 90), superuser (rank 100), and internal_service (rank 100). Each role carries a specific set of named permissions from 1 (guest) to 67 (superuser), ensuring consistent authorisation enforcement across authentication and middleware services. Role aliases such as investigator, supervisor, and org_admin map to their canonical roles automatically.

  • Scoped Administrative Permissions: The admin:full-access permission grants broad administrative actions within the caller's own tenant but does not bypass tenant isolation, secrecy-level filtering, or country restrictions. Only the superuser role bypasses those controls. This distinction prevents privilege escalation while enabling effective tenant-level administration.

  • Role Types: Functional roles (job-based), organisational roles (department or hierarchy-based), administrative roles (system management), service roles (non-human accounts), and temporary roles (time-bound elevated access). Each type carries appropriate defaults and constraints for its purpose.

  • Role Composition and Groups: Bundle related roles into groups for team-based assignment. Dynamic role assignment automatically provisions access based on user attributes such as department, job title, location, or employment type.

  • Conditional and Context-Based Roles: Activate roles based on context including on-call schedules, business hours, project membership, or geographic location. Permissions adapt automatically to the situation.

  • Delegation and Temporary Elevation: Structured workflows for temporary privilege elevation with automatic expiration, approval chains, and complete audit trails. Break-glass emergency access, incident response roles, and time-limited project assignments are all supported.

  • Separation of Duties: Define mutually exclusive role combinations and enforce segregation policies to prevent conflicts of interest. The system detects and blocks violations during role assignment.

  • Access Reviews and Certification: Automated periodic access reviews with manager certification, unused access detection, and over-privilege identification. Review campaigns track completion rates and generate compliance documentation.

  • Audit and Compliance: Complete audit trails for every role assignment, permission change, access decision, and delegation event. Pre-built reports support SOC 2, HIPAA, PCI DSS, and ISO 27001 access control requirements.

Use Cases#

  • Law enforcement agencies managing access to classified case materials, where an analyst should see only cases in their unit at or below their clearance level.
  • Government departments with strict separation of duties between those who can approve actions and those who can execute them.
  • Intelligence organisations using context-based role activation so that analysts gain expanded access only when on duty and in approved locations.
  • Financial institutions enforcing SOX segregation of duties to prevent the same individual from both initiating and approving financial transactions.
  • Healthcare providers scoping clinical access by department, shift, and patient-treating relationship, with manager certification reviews each quarter.

Open Standards#

  • OASIS XACML 3.0 (eXtensible Access Control Markup Language): The authorisation engine implements a Policy Decision Point (PDP) using OASIS XACML 3.0 attribute categories for subject, resource, and action, returning PERMIT, DENY, NOT_APPLICABLE, or INDETERMINATE decisions with Obligation elements as defined in the specification.
  • JSON Web Token, RFC 7519: Role assignments and named permissions are embedded as structured claims (roles, permissions) inside JWTs issued by the authentication service; the middleware validates issuer, audience, expiry, and signature before enforcing any access decision.
  • OAuth 2.0 / Bearer Token, RFC 6749 / RFC 6750: All integration endpoints accept OAuth 2.0 Bearer tokens for authorisation; the XACML policy service explicitly references RFC 6749 as part of its policy enforcement chain.
  • SCIM 2.0, RFC 7643 / RFC 7644: User and group provisioning across identity providers uses the System for Cross-domain Identity Management (SCIM 2.0) protocol, enabling automated role assignment from directories such as Azure AD and Okta.
  • ISO/IEC 27001:2022: The compliance engine maps RBAC controls to Annex A control A.5.15 (Access control) and A.8.2 (Privileged access rights), and evaluates account management posture against these controls for audit reporting.
  • NIST SP 800-53: Role lifecycle management and privileged account policies align with control families AC-2 (Account Management) and IA-2 (Identification and Authentication), and reports reference these control identifiers directly.
  • OAuth 2.0 and JWT Bearer Token: Token-based authentication protects typed, auditable read and write workflows across the platform.

Getting Started#

  1. Map Your Organisation: Document your organisational structure, departments, and job functions to inform role design.
  2. Design Role Hierarchy: Create your role tree with appropriate inheritance relationships and permission assignments.
  3. Configure Policies: Set up separation of duties rules, delegation constraints, and access review schedules.
  4. Assign Roles: Provision initial role assignments and configure dynamic assignment rules based on user attributes.
  5. Schedule Reviews: Establish regular access certification campaigns to maintain least-privilege posture.

Last Reviewed: 2026-04-02 Last Updated: 2026-04-14

Pronto para Integrar?

Aceda à documentação dos gateways NATO STANAG ou contacte a nossa equipa de integração de defesa para suporte.