ABAC Vision: Decision Chain Clarifications

BLUF (Bottom Line Up Front): We have aligned on the architectural logic and UI/UX strategy for integrating Attribute-Based Access Control (ABAC) with our legacy Role-Based Access Control (RBAC) system.

We evaluated whether a user failing a dynamic attribute check should fall back to their legacy role permissions, or be explicitly denied. We have concluded that the "Denied by default" logic is the only viable path forward. Permission policies will act as an absolute override, not a peer to RBAC. To simplify things, we are also proposing to remove the "Permission Locking" concept from the MVP. Furthermore, we will enforce strict Zero Trust principles by requiring explicit administrator intent for state changes, utilizing aggressive UI badging to communicate that an active Permission policy demotes the corresponding RBAC permission to a mere "Standby/Fallback" state.

Open

Below is the comprehensive logical breakdown:

Part 1: Core Architectural Logic (The "Denied by Default" Mandate)

1. The Routing Decision: Attribute Constraints are Gates, Not Suggestions

   • The Context: When an administrator attaches a dynamic Permission policy to an action (e.g., download_file requires a managed device), we must decide what happens if a user's session does not meet those attributes.

   • The Decision: The system must issue an immediate, explicit Deny.

   • The Rationale: Routing an attribute mismatch back to the legacy RBAC engine to see if the user has a baseline role (e.g., "System Admin") violates the NIST 800-207 Zero Trust framework. Static roles cannot bypass dynamic, real-time context. If a Permission policy exists, it represents the strict "Need to Know" boundary. It must override RBAC entirely, rather than falling back to it.

2. Modeling Negative Constraints via Positive Logic

   • The Logic: We do not need to build complex explicit "Deny" policies to handle "unless" scenarios. We use standard Boolean logic to translate negative constraints into positive requirements.

   • Example: "Allow everyone to download files, unless they are below the rank of Major AND on an unmanaged device."

     • Translated Policy: Action: download_file, Effect: Allow, Condition: (Rank >= Major) OR (Device == Managed).

     • Anyone failing this positive condition is automatically caught by the Option 1 Implicit Deny net.

3. Scope of Evaluation: Permission Policies Apply to Actions/Permissions, Not Users

   • The Context: There was concern that we would need to write exhaustive "Deny" lists for every user who shouldn't have access to a resource.

   • The Decision: Permission policies secure actions and resources, not specific users. If a policy governs an action, it acts as a gate for everyone attempting that action.

   • The Rationale: If a user is not part of the intended audience defined in the positive conditions of a policy (e.g., Condition: Device == Managed), they are implicitly denied by the default logic.

4. MVP Scope Reduction: Eliminating "Permission Locking"

   • The Context: We originally proposed an addition to the legacy RBAC system called "Permission Locking" that would allow an admin to "lock" an RBAC permission, strictly preventing any new Permission policies from overriding it.

   • The Decision: We are dropping the "Permission Locking" capability from the legacy RBAC flow for this MVP.

   • The Rationale: Building a dedicated "lock" to prevent an override is redundant security theater; an admin can achieve the exact same outcome by simply choosing not to create (or deleting) the Permission policy. Additionally, removing this lock check may eliminate a database or cache query from the critical path of every single user action on the platform.

Part 2: State Management & The "Override" Paradigm

1. Shattering the Symmetrical Mental Model The most dangerous assumption an administrator can make is looking at the legacy RBAC matrix, seeing a toggle set to ON, and assuming it grants access even if a Permission policy exists. It will not. If a Permission policy exists, it intercepts the request. If the attributes fail, the request dies there. It never routes back to check the RBAC toggle.

2. Legacy RBAC as a "Fallback" State Because a Permission policy intercepts the request, the legacy RBAC toggle only matters if the Permission policy is removed, deleted, or scoped out. We must train users on this fallback reality:

   • Policy Active + RBAC ON (Fail-Open): The Permission policy strictly filters access. But if the policy is deleted, the system falls back to the RBAC state, allowing everyone with that role. (Useful for safe "Shadow Mode" testing before strict enforcement).

   • Policy Active + RBAC OFF (Fail-Closed): The Permission policy strictly filters access. If the policy is deleted, the system falls back to the RBAC state, denying everyone. (The military-grade Zero Trust standard).

3. No "Auto-Magic" State Changes To achieve Impact Level 5/6 (IL5/6) auditability, we will not write backend code that automatically toggles the RBAC state to OFF the moment a Permission policy is created. Automating state changes under the hood risks catastrophic organizational lockouts if an admin makes a mistake in a new policy (or deletes it) and suddenly has no RBAC fallback. Transitioning to a "Fail-Closed" Zero Trust posture requires explicit, manual intent from the administrator.

Part 3: UI/UX Execution for the Admin Console

To ensure administrators understand the "Override" paradigm and don't misconfigure the system based on old mental models, we must update the legacy RBAC UI. When a Permission policy targets an action, the RBAC UI for that action must dynamically transform to communicate its demoted status:

• Visual Demotion: The legacy RBAC row should visually dim in some way, and a prominent badge [ 🛡️ POLICY OVERRIDE ACTIVE ] should appear in the permission row.

• Dynamic Relabeling: The toggle's tool tip text or some help text could change from standard Enabled/Disabled terminology to read: "Fallback State: Allow (Standby)" or "Fallback State: Deny (Standby)".

• Click-Interception: If an admin clicks the RBAC toggle while a Permission policy is active, a warning modal can be triggered: "⚠️ Note: This will NOT change current user access. Attribute-Based Permission policies are currently overriding this action. You are only adjusting the fallback behavior if the Permission Policies are removed."

• Deep Linking: Clicking the shield badge should route the admin directly to the policy list to view and manage the actual source of truth.