Overview

I researched case studies on permission management design and took notes.

Research Notes

I organized the information I researched, but there are still things I don't fully understand, so it's not completely organized.

Elements Composing Permissions

Permissions seem to be composed of the following elements:

Who (Principal)
What (Resource)
What actions (Action) are allowed (ALLOW) or not allowed (DENY)

Permission Design Methods

The following methods are generally considered for design:

ACL (Access Control List)
- Set permissions for each user
- Permissions are managed in a list
RBAC (Role Based Access Control)
- Assign roles to users and assign permissions to roles
ABAC (Attribute Based Access Control)
- Set permissions based on attributes of users, resources, environments, etc.

The flexibility of permissions and the complexity of implementation are ACL < RBAC < ABAC.

Perspectives on Permission Design

The following perspectives seem relevant for permission design:

Scope of Permission Application
- How far do permissions apply?
- Functional scope
  - Can target a single function or a specific group of functions
  - ex. Whether the user information retrieval API can be used
- Data scope
  - The most primitive scope of permission application
  - ex. Viewing permissions for user information → Can see name and age but not address
- Sometimes both need to be considered, while other times only one is sufficient, but flexible design is required
Control Targets of Permissions
- On what basis are permissions applied?
  - Content
    - Apply permissions to specific functions, data, etc.
  - Context
    - Apply permissions based on whether specific conditions are met
      - ex. Only users with a transaction amount of 1 million yen or more can access
    - Is it even a target managed as a permission? If managed as a permission, how is the state managed?
  - Time
    - Apply permissions only during specific time periods
      - ex. Accessible only on weekdays
    - Access permissions are also within the scope of permissions
Constraints of Permissions
- Constraints such as priority of permissions and dependencies between permissions
- Conflicting permissions
  - If a user has permissions to view only specific data but also has permissions to view all data, which takes precedence?
  - How to express the relationship of conflicting permissions?
    - Considerations for implementation include evaluating manually when adding new permissions, defining priorities based on attributes or roles, or using a set-theoretic approach
    - May need to consider from the perspective of user experience and security (principle of least privilege)
Layers of Permission Application
- Which layer of the system is permission applied to?
  - Application, database, network, OS, etc.
- From where is permission application necessary?
- The layer seems to be determined by the functional and data scope settings
Handling of Administrator Permissions
- How to set administrator permissions
- Administrator permissions pose a security risk
  - Need to consider risk management perspectives such as the principle of least privilege, separation of duties, audit logs, and emergency operations
Operational Flow of Permission Management
- Need to consider an operational flow for proper permission management
- Principle of least privilege
  - Grant only the minimum necessary permissions
- Regular audits and reviews
  - Regularly check permission settings and remove unnecessary permissions
- Centralized management
  - Provide an interface that makes it easy to understand the types of permissions and their application status
  - Consistent permission application flow
    - If permission management is uniquely implemented in each system, consistency is likely to be disrupted (I think)
  - Separation of permissions
    - Flexible permission settings should be possible
    - The control target of a single permission should not be too broad

Required System Characteristics

Considered the system characteristics required for a system that manages permissions.

Extensibility
- Can add permissions with any flexibility
Scalability
- A highly flexible permission design is likely to increase system complexity and data volume
- Consider capacity when users and permissions increase linearly
Reliability
- Ensure that adding or changing permissions does not adversely affect existing permissions
Security
- Adhere to the principle of least privilege, minimize blast radius, and prepare emergency operations for failures

Impressions

Although it's a general impression as it depends on the industry and business domain of the service, I think permission management is particularly demanded in B2B services.

It seems like there isn't a well-established body of information or best practices.

It seems like a field where you could write a whole book, but there don't seem to be many related books.

I feel like I've identified the perspectives to consider, but the particularly challenging part seems to be how much flexibility to allow in permissions. I thought it would be necessary to expand the design while considering future business requirements to some extent.