Difference between revisions of "User Access not User Identity"

From MgmtWiki
Jump to: navigation, search
(Context)
(Conclusion)
Line 91: Line 91:
  
 
Systems focused on delegating specific rights temporarily and securely.
 
Systems focused on delegating specific rights temporarily and securely.
 +
 +
===Membership based===
 +
This also covers and payment-based or ticket access. A related access control is by travel card which is common on local transit.
  
 
===Conclusion===
 
===Conclusion===

Revision as of 14:36, 26 May 2025

Meme

The desire of digital sites to control access to a certain category of users should not require leaning the user's Identity.

Context

Here’s an overview of the main approaches where any type of dynamic, parameter-based access control makes sense:

Identity-Based Access Control (IBAC)

What It Is: Access decisions are made solely based on the verified identity of a user. Every request is coupled with a unique identity, often established via usernames, digital certificates, or biometric data.

When It Makes Sense:

Systems that need to audit individual activities.

Environments where personal accountability is paramount.

Scenarios where tying access directly to a verified identity is the simplest and most direct approach.

Role-Based Access Control (RBAC)

What It Is: Access is granted based on a user’s role within an organization. Each role is predefined with a set of privileges, and users inherit these privileges when assigned to the role.

When It Makes Sense:

Large organizations where permissions need to be grouped by job functions.

Environments that benefit from simplified administration by mapping roles to responsibilities.

Systems where a stable structure of roles can cover most or all access needs.

Attribute-Based Access Control

What It Is: Decisions are based on a combination of attributes associated with users, resources, and the current environment. These attributes might include user clearance, department, resource sensitivity, time of access, or even device type.

When It Makes Sense:

Environments requiring fine-grained, flexible policy decisions.

Systems where access must adapt dynamically to changing conditions.

Multi-dimensional scenarios where the interplay of several factors determines whether access should be granted.

Context-Based Access Control

What It Is: A specialized form of ABAC that focuses on real-time contextual factors such as geographic location, time of day, device security posture, or network environment.

When It Makes Sense:

Mobile or remote environments where a user’s location and context (e.g., accessing from a known network vs. a public Wi-Fi) are significant.

Situations demanding granular control over when and where sensitive operations occur.

Systems that need to lower risk during non-standard hours or off-site usage.

Risk-Based Access Control

What It Is: Access decisions are influenced by an ongoing evaluation of risk. This can include factors like user behavior anomalies, security posture of the request origin, and historical security incidents.

When It Makes Sense:

Dynamic environments where risk levels can fluctuate rapidly.

Systems that adjust permissions or require additional verification if the risk of a particular transaction is deemed higher.

Scenarios where adaptive security measures are essential to mitigate evolving threats.

Mandatory Access Control (MAC)

What It Is: A strict, centrally enforced model where access is governed by a fixed policy. Both data and subjects have classifications, and access is granted only if the subject’s clearance meets or exceeds the resource’s classification.

When It Makes Sense:

High-security environments (e.g., military, government systems) where rigid policy enforcement is necessary.

Systems where discretionary access by end users might introduce unacceptable risk.

Settings that require non-negotiable separation between different security levels.

Discretionary Access Control (DAC)

What It Is: Resource owners control access. They decide who may have access to their resources and can grant or remove permissions at their discretion.

When It Makes Sense:

Environments that favor flexibility and user control over data.

Systems where the relationship between users is trusted enough to allow owners to manage permissions.

Scenarios where formal, centralized control is either not feasible or too restrictive.

Capability-Based Access Control

What It Is: Instead of checking a user’s identity or attributes directly, access rights are determined by unforgeable tokens (capabilities) that a user possesses. These tokens explicitly list the actions that can be performed on a resource.

When It Makes Sense:

Distributed systems or microservices architectures where passing tokens is more efficient than querying centralized policies.

Environments where fine-grained, revocable permissions are required.

Systems focused on delegating specific rights temporarily and securely.

Membership based

This also covers and payment-based or ticket access. A related access control is by travel card which is common on local transit.

Conclusion

Each access control model is designed to address a unique set of challenges and operational contexts. Choosing the right model—or a hybrid combination—requires analyzing factors such as organizational structure, the dynamic nature of the environment, the sensitivity of the resources, and regulatory requirements. For instance, while RBAC provides simplicity for well-defined roles, ABAC or context-based models offer the flexibility needed for dynamic, real-time decision-making.

Problems

Solutions

References