Understanding Permissions: Definitions, Design Principles, Role Relationships, and Security Frameworks

The article begins by clarifying what a permission is, noting that it can have both noun attributes (e.g., API, page, feature) and verb attributes (e.g., operable, non‑operable), and that a permission essentially expresses a "what" (object) and a "how" (operation).

Two main design principles are presented: the principle of least privilege , which advocates splitting permissions to avoid granting users unnecessary access, and the data abstraction principle , which focuses on defining operations (often expressed as CRUD) and extending them for more complex relationships such as assignment permissions.

In a front‑end/back‑end separated architecture, the article distinguishes server‑side permissions (which protect API or RPC services) from client‑side permissions (which control page visibility and UI element actions). It explains that the server can only enforce access to its services, while the front‑end or mobile client is responsible for visual and functional access control.

The relationship between roles and permissions is then examined. Roles are described as higher‑level aggregates of permissions that simplify management, reduce duplication, and support static and dynamic responsibility division (e.g., mutually exclusive roles, limited role counts, or single‑active‑role constraints). This leads to a complete RBAC (Role‑Based Access Control) model.

For data‑model design, the article discusses when a dedicated permission table is necessary, how to handle multiple permission objects (pages, APIs, etc.), and proposes adding business‑module and operation tables to decouple page‑API bindings while keeping maintenance effort reasonable.

Finally, common Java security frameworks are compared. Shiro is recommended for its simplicity in learning RBAC concepts, while Spring Security offers richer features but a steeper learning curve. The choice depends on the project’s needs and the developer’s familiarity.