# Access Control Mechanisms **ABAC (Attribute-Based Access Control):** * Decisions are based on user attributes (e.g., department, clearance level). * Requires an attribute store linked to users. **RBAC (Role-Based Access Control):** * Access decisions are based on user roles. * Roles are associated with specific permissions. **UBAC (User-Based Access Control):** * User-specific access permissions. * Allows defining permissions directly on individual users. **CBAC (Context-Based Access Control):** * Decisions are based on context (e.g., location, device). * Requires contextual data to be evaluated at runtime. **Rule-Based Access Control:** * Policies are defined by complex rules, such as combinations of attributes, roles, and context. * Rules are evaluated dynamically to determine access. **Time-Based Access Control:** * Access is restricted based on time (e.g., only during business hours). **JSON Models** **User Model** ```json { "userId": "string", "username": "string", "email": "string", "role": ["roleId1","roleId2"], "attributes": { "department": "string", "clearanceLevel": "int", "location": "string", "device": "string" }, "permissions": ["permission1", "permission2"], } ``` * **Explanation:** The user model includes attributes for ABAC and a user can have more than one role. **Role Model** ```json { "roleId": "string", "roleName": "string", "permissions": ["permissionId1", "permissionId2"] } ``` * **Explanation:** The role model lists permissions associated with the role, supporting RBAC. **Permission Model** ```json { "permissionId": "string", "permissionName": "string", "description": "string", "applicationId": "string", "hierarchicalStructure": { "parentPermissionId": "string", "childPermissions": ["permissionId1", "permissionId2"] } } ``` * **Explanation:** The permission model supports hierarchical structuring within an application context, making it easier to organize permissions. **Client Model** ```json { "clientId": "string", "clientSecret": "string", "redirectUris": ["string"], "accessControl": { "abac": true, "rbac": true, "ubac": true, "cbac": true, "ruleBased": true, "timeBased": true } } ``` **Policy/Resource Model** ```json { "policyId": "string", "conditions": { "attributes": { "department": "IT", "clearanceLevel": 5 }, "roles": ["Admin"], "context": { "location": "HQ", "device": "CorporateDevice" }, "rules": [ { "ruleId": "string", "ruleLogic": "((department == 'IT') AND (clearanceLevel > 3))" } ], "time": { "start": "09:00", "end": "17:00", "timezone": "UTC" } }, "permissions": ["permissionId1", "permissionId2"], "effect": "allow | deny", "evaluationOrder": ["roles", "attributes", "context", "rules", "time"] } ``` * **Explanation:** * * **Permissions:** Policies include permissions to determine what actions are allowed or denied based on evaluated conditions. * * **Effect:** The effect field determines the outcome of the policy (allow or deny). * * **Evaluation Order:** The evaluationOrder field defines the sequence in which conditions are evaluated, helping to manage conflicts and dependencies. **Policy Inheritance** Policy Inheritance allows specific policies to override more general ones. This is useful in scenarios where multiple policies might apply to the same user or resource, but one needs to take precedence. **Policy Model with Inheritance** ```json { "policyId": "string", "parentPolicyId": "string", // Reference to a more general policy "conditions": { "attributes": { "department": "IT", "clearanceLevel": 5 }, "roles": ["Admin"], "context": { "location": "HQ", "device": "CorporateDevice" }, "rules": [ { "ruleId": "string", "ruleLogic": "((department == 'IT') AND (clearanceLevel > 3))" } ], "time": { "start": "09:00", "end": "17:00", "timezone": "UTC" } }, "permissions": ["permissionId1", "permissionId2"], "effect": "allow | deny", "evaluationOrder": ["roles", "attributes", "context", "rules", "time"], "priority": 1 // Lower number indicates higher priority } ``` * **Explanation:** * * **parentPolicyId:** This field allows a policy to inherit from another, more general policy. If the child policy is more specific, it will override the parent policy's conditions or effects. * * **priority:** Policies can be assigned a priority level. When multiple policies apply, those with higher priority (lower numerical value) are evaluated first. **Conflict Resolution** When multiple policies apply to a user or resource, Conflict Resolution strategies ensure that the system consistently handles situations where one policy might allow access, and another might deny it. **Policy Conflict Model** ```json { "policyId": "string", "parentPolicyId": "string", "conditions": { "attributes": { "department": "IT", "clearanceLevel": 5 }, "roles": ["Admin"], "context": { "location": "HQ", "device": "CorporateDevice" }, "rules": [ { "ruleId": "string", "ruleLogic": "((department == 'IT') AND (clearanceLevel > 3))" } ], "time": { "start": "09:00", "end": "17:00", "timezone": "UTC" } }, "permissions": ["permissionId1", "permissionId2"], "effect": "allow | deny", "evaluationOrder": ["roles", "attributes", "context", "rules", "time"], "priority": 1, "conflictResolution": "deny-overrides | allow-overrides | first-applicable | highest-priority" // Strategy for resolving conflicts "status": "active | inactive | deprecated" } ``` * Explanation: * * **conflictResolution:** Defines the strategy for resolving conflicts between multiple applicable policies: * * * **deny-overrides:** Deny policies take precedence over allow policies. * * * **allow-overrides:** Allow policies take precedence over deny policies. * * * **first-applicable:** The first applicable policy in evaluation order is enforced. * * **highest-priority:** The policy with the highest priority (lowest numerical value) is enforced.