Understanding the Essence of Permissions: Resources, Access, and Authorization Models
This article explains the fundamental nature of permissions as limited licensed access to protected resources, defines what constitutes a resource in software, outlines resource identification and limitation, and describes permission classifications, control models, and authorization mechanisms such as role‑based access.
1. Essence of Permission Permission management starts with understanding that a permission is a limited licensed access to a protected resource.
2. Concept of Resource In computing, a resource refers to any object used by software—functions, files, network endpoints, UI elements like buttons or pages, and even database fields. Properly defining resources is the first step in permission discussions.
2.1 Resource Identification When many resources exist, they should be given identifiers and organized into categories to simplify management.
2.2 Limited Resources Only resources that are both protected and limited need permission control; public or unlimited resources generally do not require protection.
3. Concept of Permission
3.1 Permission Classification Permissions are not standalone; they attach to a subject. They can be classified by authorization method (department, personnel, role) and by software layer (functional, business, data). Functional permissions cover UI elements, business permissions cover whole business processes, and data permissions control access to specific data objects.
3.2 Permission Control Model A permission consists of a receptor (the resource) and a ligand (the access key held by the accessor). The ligand must bind to the receptor for the permission to succeed, analogous to a key unlocking a lock. The model also distinguishes owners and executors; anyone holding the appropriate key can access the protected resource.
3.3 Permission Authorization Roles are collections of permissions; assigning permissions by role simplifies management. Permissions can also be granted by department, individual, or a combination of these, and clear authorization is essential to avoid conflicts.
Summary A permission system comprises three core parts: (1) the resources to be protected (menus, buttons, pages, data, etc.), (2) the identification and grouping of those protected resources, and (3) the authorization process (role‑based, department‑based, or personal) that grants access.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.