LESSON 3: AUTHORIZATION AND ACCESS CONTROL MODELS

Lesson Overview

This lesson covers authorization and access control models for Digital Product Passport implementations. Students will learn about role-based access control, attribute-based access control, fine-grained permissions, multi-party access management, and how to implement effective authorization for DPP ecosystems. The lesson provides practical guidance on building access control foundations for secure DPP systems.

Learning Objectives

• Design authorization architectures for DPP systems
• Implement role-based access control (RBAC)
• Implement attribute-based access control (ABAC)
• Design fine-grained permission models
• Manage multi-party access across organizational boundaries
• Implement access control lifecycle management

Detailed Content

Authorization Overview

Authorization determines what authenticated entities can do—what resources they can access and what operations they can perform. For DPP systems with complex data ownership models and multi-party ecosystems, authorization must be both precise and flexible.

Authorization vs Authentication: Authentication verifies who an entity is (identity). Authorization determines what that entity can do (permissions). Authentication must precede authorization—entities must be authenticated before their permissions can be evaluated. For DPP systems, both are required—authentication establishes identity, authorization enforces access rights.

Authorization Principles: Effective authorization follows specific principles. Principles include least privilege (grant minimum necessary access), need-to-know (grant access only to information needed for role), and separation of duties (split critical responsibilities across multiple roles). Principles should guide all authorization design. For DPP systems, least privilege is particularly important for minimizing the impact of compromised accounts.

Access Control Models: Different models implement authorization. Models include discretionary access control (DAC - owner controls access), mandatory access control (MAC - system controls access based on labels), role-based access control (RBAC - access based on roles), and attribute-based access control (ABAC - access based on attributes). Model selection should be based on requirements and complexity. For DPP systems, RBAC and ABAC are most commonly used.

Policy Enforcement: Authorization policies must be enforced at multiple layers. Enforcement includes application-level enforcement (enforce in application code), API-level enforcement (enforce in API gateway), and data-level enforcement (enforce in database). Multi-layer enforcement provides defense in depth. For DPP systems, enforcement at API level is essential, with data-level enforcement for particularly sensitive data.

Role-Based Access Control (RBAC)

RBAC assigns permissions to roles, and roles to users. This simplifies administration by managing permissions at the role level rather than the individual user level.

RBAC Components: RBAC includes several components. Components include roles (collections of permissions), permissions (specific access rights), role assignments (users assigned to roles), and role hierarchies (roles can inherit from other roles). Components should be designed to reflect organizational structure and job functions. For DPP systems, RBAC roles should reflect supply chain roles (manufacturer, supplier, regulator, consumer).

Role Design: Effective role design is critical for RBAC success. Design principles include role granularity (roles should be appropriately granular), role stability (roles should be stable over time), and role clarity (role purpose should be clear). Design should avoid role explosion (too many roles) and role ambiguity (unclear role boundaries). For DPP systems, roles should align with business functions rather than individual tasks.

Permission Design: Permissions define specific access rights. Design includes resource identification (what resources can be accessed), action identification (what actions can be performed), and scope definition (scope of access). Permissions should be atomic and composable. For DPP systems, permissions might include "read passport", "write passport", "approve passport", "delete passport" with scope by product type or organization.

RBAC Limitations: RBAC has limitations in complex environments. Limitations include role explosion (many roles needed for fine-grained control), static nature (roles don't adapt to context), and organizational dependency (roles tied to organizational structure). These limitations can be addressed by combining RBAC with ABAC. For DPP systems, RBAC alone may be insufficient for complex multi-party access requirements.

Attribute-Based Access Control (ABAC)

ABAC evaluates access based on attributes of the subject, resource, action, and environment. ABAC provides more fine-grained and context-aware access control than RBAC.

ABAC Components: ABAC includes several components. Components include subject attributes (user attributes like role, department), resource attributes (resource attributes like classification, owner), action attributes (action attributes like read, write), and environment attributes (context like time, location). Components are evaluated against policies to determine access. For DPP systems, ABAC can consider subject organization, resource ownership, and supply chain relationship.

Policy Language: ABAC requires a policy language to define access rules. Languages include XACML (eXtensible Access Control Markup Language - standard policy language), Rego (policy language for OPA), and custom DSLs (domain-specific languages). Language selection should be based on requirements and tooling. For DPP systems, XACML or Rego are commonly used for policy definition.

Policy Evaluation: ABAC policies are evaluated at access time. Evaluation includes attribute collection (collect relevant attributes), policy matching (match policies to request), and decision (allow or deny). Evaluation should be efficient and should handle edge cases. For DPP systems, policy evaluation must be fast enough to not impact API performance.

ABAC Advantages: ABAC provides several advantages over RBAC. Advantages include fine-grained control (control based on multiple attributes), context awareness (consider time, location, other context), and flexibility (policies can adapt without role changes). ABAC is particularly valuable for complex environments. For DPP systems, ABAC is valuable for multi-party access based on supply chain relationships.

Fine-Grained Permissions

Fine-grained permissions provide precise control over what entities can do. For DPP systems with sensitive data and complex access requirements, fine-grained permissions are essential.

Permission Granularity: Permission granularity defines how specific permissions are. Granularity levels include coarse-grained (broad permissions like "read all data"), medium-grained (permissions by resource type like "read passports"), and fine-grained (permissions by specific resource like "read passport X"). Granularity should balance security with manageability. For DPP systems, fine-grained permissions at the passport level may be appropriate for particularly sensitive data.

Permission Composition: Permissions can be composed from more granular permissions. Composition includes atomic permissions (indivisible permissions), composite permissions (composed of atomic permissions), and permission hierarchies (permissions inherit from parent permissions). Composition should be logical and should avoid conflicts. For DPP systems, "manage passport" might be composed of "read", "write", and "delete" permissions.

Scope-Based Permissions: Permissions can be scoped to specific contexts. Scopes include organizational scope (permissions within organization), product scope (permissions for specific product types), and data scope (permissions for specific data classifications). Scope-based permissions provide flexibility while maintaining security. For DPP systems, scope-based permissions enable suppliers to access only their own data within manufacturer systems.

Permission Inheritance: Permissions can be inherited through hierarchies. Inheritance includes role inheritance (roles inherit from parent roles), organizational inheritance (inherit permissions through organizational hierarchy), and delegation (delegate permissions to subordinates). Inheritance should be controlled to prevent permission creep. For DPP systems, permission inheritance should be carefully designed to prevent unauthorized access.

Multi-Party Access Management

DPP ecosystems involve multiple organizations with different access requirements. Multi-party access management must address cross-organizational access while maintaining security.

Cross-Organizational Access: Cross-organizational access enables entities from one organization to access resources in another organization. Access includes supplier access (suppliers access manufacturer systems), partner access (partners access each other's systems), and regulator access (regulators access industry systems). Access should be based on business relationships and should be time-bound. For DPP systems, cross-organizational access is essential for supply chain collaboration.

Trust Boundaries: Trust boundaries define which organizations are trusted for what access. Boundaries include trusted partners (full access for trusted partners), limited partners (limited access for specific purposes), and untrusted entities (no access or very limited access). Boundaries should be documented and should be enforced technically. For DPP systems, trust boundaries are particularly important for protecting competitive information.

Data Ownership-Based Access: Access can be based on data ownership. Owners include data originator (organization that created data), data custodian (organization storing data), and data consumer (organization consuming data). Access rights should reflect ownership relationships. For DPP systems, data ownership-based access enables suppliers to access their own data while protecting manufacturer data.

Supply Chain Access Patterns: Different patterns enable supply chain access. Patterns include tiered access (access based on supply chain tier), relationship-based access (access based on business relationship), and event-based access (temporary access for specific events). Pattern selection should be based on supply chain structure. For DPP systems, tiered access is common—tier 1 suppliers have broader access than tier 2 suppliers.

Access Control Lifecycle

Access control must be managed throughout its lifecycle to ensure permissions remain appropriate.

Access Request: Access request processes enable entities to request access. Processes include self-service requests (users request access through portal), manager approval (manager approves requests), and automated provisioning (automatically grant approved access). Processes should be efficient and should include audit trail. For DPP systems, access request processes are particularly important for onboarding new suppliers and partners.

Access Review: Regular access reviews ensure permissions remain appropriate. Reviews include periodic reviews (regular review of all access), event-triggered reviews (review on role change), and access certification (managers certify access is still needed). Reviews should identify and revoke unnecessary access. For DPP systems, access reviews are essential for maintaining least privilege over time.

Access Revocation: Access must be revoked when no longer needed. Revocation includes immediate revocation (revoke immediately on termination), scheduled revocation (revoke at scheduled time), and conditional revocation (revoke based on conditions). Revocation should be comprehensive across all systems. For DPP systems, access revocation is particularly important when supplier relationships end.

Exception Management: Some access requests may require exceptions to standard policies. Exception management includes exception request (request exception), exception approval (approve with justification), and exception tracking (track exceptions for review). Exceptions should be time-bound and should require higher-level approval. For DPP systems, exception management enables flexibility while maintaining security oversight.

Access Control Architecture

Access control architecture defines how authorization is implemented across the system.

Centralized Authorization: Centralized authorization uses a central authorization service. Architecture includes policy decision point (PDP - makes authorization decisions), policy enforcement point (PEP - enforces decisions), and policy administration point (PAP - manages policies). Centralized provides consistency but may be a bottleneck. For DPP systems, centralized authorization is appropriate for consistency across services.

Distributed Authorization: Distributed authorization implements authorization in each service. Architecture includes local policy engines (each service has policy engine), policy distribution (distribute policies to services), and local enforcement (enforce locally). Distributed provides scalability but requires policy synchronization. For DPP systems, distributed authorization is appropriate for microservices architectures.

Hybrid Authorization: Hybrid authorization combines centralized and distributed approaches. Centralized for policy management and decision-making, distributed for enforcement. Hybrid provides benefits of both approaches. For DPP systems, hybrid authorization is commonly used—centralized PDP for decisions, distributed PEPs for enforcement.

API Gateway Authorization: API gateway can enforce authorization at the gateway level. Architecture includes gateway enforcement (enforce before request reaches service), policy integration (integrate with authorization service), and performance optimization (cache authorization decisions). Gateway authorization provides consistent enforcement but may not support fine-grained resource-level authorization. For DPP systems, API gateway authorization is appropriate for coarse-grained access control with service-level authorization for fine-grained control.

Technical Concepts

• Authorization: Determining what authenticated entities can do
• RBAC (Role-Based Access Control): Access based on roles
• ABAC (Attribute-Based Access Control): Access based on attributes
• DAC (Discretionary Access Control): Owner controls access
• MAC (Mandatory Access Control): System controls access based on labels
• Least Privilege: Grant minimum necessary access
• Need-to-Know: Grant access only to information needed for role
• Separation of Duties: Split critical responsibilities across multiple roles
• Permission: Specific access right
• Role: Collection of permissions
• Policy: Rule defining access
• XACML: eXtensible Access Control Markup Language
• Rego: Policy language for OPA
• PDP (Policy Decision Point): Makes authorization decisions
• PEP (Policy Enforcement Point): Enforces authorization decisions
• PAP (Policy Administration Point): Manages policies
• Trust Boundary: Boundary defining trusted access

Architecture Considerations

Authorization Architecture: Design authorization architecture based on requirements. Consider RBAC (simpler, less flexible) vs ABAC (more complex, more flexible). RBAC is appropriate for simpler requirements. ABAC is appropriate for complex multi-party access. For DPP systems, hybrid RBAC+ABAC is often appropriate—RBAC for basic roles, ABAC for fine-grained multi-party access.

Policy Architecture: Design architecture for policy management. Consider centralized policy (central policy store) vs distributed policy (policies distributed to services). Centralized provides consistency but may be bottleneck. Distributed provides scalability but requires synchronization. For DPP systems, centralized policy with distributed enforcement is common.

Enforcement Architecture: Design architecture for policy enforcement. Consider gateway enforcement (enforce at API gateway) vs service enforcement (enforce in services). Gateway enforcement provides consistency but may lack context. Service enforcement provides context but may be inconsistent. For DPP systems, gateway enforcement for coarse-grained, service enforcement for fine-grained is a common hybrid.

Multi-Party Architecture: Design architecture for multi-party access. Consider federated authorization (each organization enforces its own policies) vs centralized authorization (central authorization for ecosystem). Federated provides autonomy but requires coordination. Centralized provides consistency but may not respect autonomy. For DPP systems, federated authorization with central policy coordination is appropriate.

Lifecycle Architecture: Design architecture for access control lifecycle. Architecture should include automated provisioning (automate access grants), automated revocation (automate access revocation), and regular reviews (periodic access review). Architecture should minimize manual intervention. For DPP systems, lifecycle architecture is essential for maintaining security over time.

Implementation Considerations

RBAC Implementation: Implement RBAC for basic access control. Implementation includes role definition (define roles and permissions), role assignment (assign users to roles), and role enforcement (enforce role-based access). Implementation should be simple and should avoid role explosion. For DPP systems, RBAC implementation should cover basic internal roles (admin, user, auditor).

ABAC Implementation: Implement ABAC for fine-grained and context-aware access control. Implementation includes attribute definition (define subject, resource, action, environment attributes), policy definition (define policies in policy language), and policy engine (implement policy evaluation). Implementation should be efficient and should handle complex policies. For DPP systems, ABAC implementation should handle multi-party access based on supply chain relationships.

Policy Engine Implementation: Implement policy engine for authorization decisions. Implementation includes policy storage (store policies), policy evaluation (evaluate policies against requests), and decision caching (cache decisions for performance). Implementation should use standard policy languages where possible. For DPP systems, policy engine implementation should support both RBAC and ABAC policies.

Access Review Implementation: Implement access review processes. Implementation includes review scheduling (schedule regular reviews), review workflows (implement review and approval workflows), and revocation automation (automate revocation of unapproved access). Implementation should be efficient and should provide audit trail. For DPP systems, access review implementation is essential for maintaining least privilege.

Monitoring Implementation: Implement monitoring for access control. Monitoring includes access logging (log all access attempts), policy monitoring (monitor policy effectiveness), and anomaly detection (detect anomalous access patterns). Monitoring should provide alerts for security issues. For DPP systems, access monitoring is essential for detecting unauthorized access attempts.

Enterprise Examples

Battery Access Control: A European automotive manufacturer implemented comprehensive access control for EV battery passport system. RBAC defined basic roles (admin, supplier, auditor). ABAC enabled fine-grained multi-party access based on supply chain relationships—suppliers could access only their own data. Data ownership-based access ensured manufacturers couldn't access supplier competitive data. Regular access reviews maintained least privilege. The implementation enabled secure multi-party access while protecting competitive information.

Textile Access Control: A European textile industry association implemented access control for textile passport platform. ABAC policies defined access based on organizational role and data ownership. Member organizations could access their own data and data they had permission to access. Regulators had broader access for compliance verification. Centralized policy engine provided consistent enforcement across platform services. The implementation enabled industry-wide participation while maintaining data sovereignty and security.

Electronics Access Control: A consumer electronics manufacturer implemented access control for electronic product passport system. RBAC defined internal roles (product manager, engineer, auditor). ABAC enabled cross-organizational access for suppliers and partners. Tiered access patterns provided different access levels based on supply chain tier. Automated provisioning and deprovisioning managed supplier lifecycle. The implementation enabled secure global supply chain collaboration while maintaining appropriate access controls.

Common Mistakes

Over-Privileged Accounts: Granting excessive permissions, resulting in security risk. Accounts should have minimum necessary access. Over-privileged accounts increase the impact of compromised accounts. Least privilege should be enforced through regular access reviews.

Role Explosion: Creating too many roles, resulting in management complexity. Roles should be designed to be stable and should avoid excessive granularity. Role explosion makes RBAC difficult to manage. Consider ABAC for fine-grained control.

No Multi-Party Model: Not addressing multi-party access requirements, resulting in inability to support supply chain collaboration. Multi-party access model is essential for DPP ecosystems. No multi-party model forces workarounds that compromise security.

Static Policies: Using static policies that don't adapt to context, resulting in inability to handle complex access scenarios. Policies should be context-aware and should adapt to changing conditions. Static policies limit flexibility and may require exceptions.

No Access Reviews: Not performing regular access reviews, resulting in permission creep. Access reviews should be periodic and should revoke unnecessary access. No access reviews leads to excessive permissions over time.

Best Practices

Least Privilege: Implement least privilege for all access. Entities should have minimum necessary access for their role. Least privilege should be enforced through role design and regular access reviews. Least privilege minimizes the impact of compromised accounts.

RBAC + ABAC: Combine RBAC and ABAC for comprehensive access control. RBAC for basic roles and simple scenarios. ABAC for fine-grained and context-aware access. Combination provides simplicity where needed and flexibility where needed.

Data Ownership-Based Access: Implement access based on data ownership. Data originators should control access to their data. Ownership-based access enables multi-party collaboration while protecting competitive information. Data ownership-based access is essential for DPP ecosystems.

Regular Access Reviews: Perform regular access reviews. Reviews should identify and revoke unnecessary access. Reviews should be automated where possible and should include manager certification. Regular access reviews maintain least privilege over time.

Policy as Code: Implement policies as code. Policies should be version-controlled, tested, and deployed like code. Policy as code enables consistent policy management and reduces errors. Policy as code is particularly valuable for ABAC policies.

Comprehensive Monitoring: Monitor all access control events. Monitoring should include access attempts, policy decisions, and anomalous patterns. Monitoring enables detection of unauthorized access and policy issues. Comprehensive monitoring is essential for security visibility.

Key Takeaways

• Authorization determines what authenticated entities can do
• RBAC assigns permissions to roles, roles to users
• ABAC evaluates access based on subject, resource, action, and environment attributes
• Fine-grained permissions provide precise control over access
• Multi-party access management addresses cross-organizational access requirements
• Access control lifecycle includes request, review, revocation, and exception management
• Architecture patterns include centralized, distributed, and hybrid authorization
• Implementation considerations include RBAC, ABAC, policy engine, access review, and monitoring
• Common mistakes include over-privileged accounts, role explosion, no multi-party model, static policies, and no access reviews
• Best practices include least privilege, RBAC+ABAC, data ownership-based access, regular access reviews, policy as code, and comprehensive monitoring