Skip to content

Use Case & User Stories: Access Control Model Foundation (RBAC/GBAC)
Use Case ID: UC-04
Use Case Name: Evaluate User's Effective Permissions for an Action
Feature: Access Control Model Foundation (RBAC/GBAC)
Actors: System (Primary), All Authenticated Users (Secondary)

1. Use Case Description

This use case describes the internal, non-visible process the system must execute whenever a user attempts to perform any protected action. The system calculates the user's complete set of permissions ("effective permissions") in real-time by inspecting their group memberships and the roles assigned to those groups. It then checks if the specific permission required for the attempted action is present in this calculated set. This is the core security evaluation that enforces the Principle of Least Privilege across the entire application.

2. User Stories

  • US-13: Enforce Principle of Least Privilege > As an IT Security Officer, > I want the system to grant access based on a strict, additive model where permissions are inherited only through a user's group memberships, > so that I can be confident that the Principle of Least Privilege is enforced by default.

  • US-14: Simplify Permission Management > As a System Administrator, > I want to manage user access by assigning roles to groups instead of assigning permissions to individual users, > so that I can update the access rights for an entire team (e.g., the "Marketing Department") with a single action.

  • US-15: Scalable and Auditable Access Control > As a System Architect, > I want a security model that strictly prohibits direct assignment of roles or permissions to a user, > so that the access control system remains auditable, consistent, and scalable as the organization grows.

  • US-16: Combine Permissions from Multiple Groups > As a System Administrator, > I want a user who belongs to multiple groups to receive the combined permissions from all roles associated with those groups, > so that I can grant complex access rights to users with cross-functional responsibilities (e.g., a manager who is also a content approver).

3. Preconditions

  • A user is authenticated and has an active session.
  • The system has a defined set of Permissions, Roles, and Groups.
  • Roles have been assigned to Groups, and the user is a member of at least one Group.

4. Postconditions

  • On Success: The system allows the user's action to proceed.
  • On Failure: The system blocks the user's action and triggers the "Unauthorized Access" handling procedure.

5. Main Success Scenario (Happy Path)

Step User Action / Trigger System Response
1 A user, Alice, initiates a protected action (e.g., clicks a "Create New Article" button). The system identifies the specific permission string required for the action (e.g., article:create).
2 System retrieves the list of all Groups Alice is a member of (e.g., "Marketing Content Creators").
3 System retrieves the list of all Roles assigned to those groups (e.g., "Content Editor").
4 System compiles a complete, unique list (a union) of all Permission strings contained within all of those roles. This is Alice's "effective permissions" list (e.g., [article:create, article:edit, asset:upload]).
5 System evaluates if the required permission (article:create) exists in the effective permissions list.
6 The check is successful. The system allows the action to proceed, and Alice is directed to the new article creation page.

6. Alternative & Exception Flows

  • 5a. Failure Case - Insufficient Permissions:
    • A user, Bob, attempts an action that requires the user:view:list permission.
    • The system follows steps 2-4 and calculates Bob's effective permissions (e.g., [report:view:sales, dashboard:view]).
    • At step 5, the system evaluates if user:view:list exists in Bob's effective permissions list. The check fails.
    • The system immediately blocks the action and triggers the standard "Unauthorized Access" handling procedure (as defined in its own BRD).