SCM Access Control Using Smart Contracts for Dynamic Workflows

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional Role-Based Access Control (RBAC) systems in Source Code Management (SCM) are inadequate for managing dynamic and intricate collaborative workflows in multi-party development projects, failing to adapt to changing project needs, potentially exposing business secrets and disrupting workflows.

Innovation Solution

A Workflow-Aware Access Control (WFAC) system using smart contracts on a semi-private blockchain dynamically updates access policies in real-time, leveraging metadata and policy templates for nuanced permissions, ensuring adaptability and security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If Role-Based Access Control (RBAC) is used to manage access permissions in SCM systems, then access control structure is improved, but adaptability to dynamic workflows deteriorates

Engineering Contradiction:
Improveaccess control structureVSAvoidadaptability to dynamic workflows
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic access control by transitioning from static RBAC roles to workflow-stage-based permissions. Access rights are automatically adjusted based on the current workflow stage and participant roles, allowing the system to adapt dynamically to changing collaboration requirements without manual reconfiguration.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the parameter of access control from fixed role assignments to variable permissions based on workflow context. By introducing workflow stage as a dynamic parameter, the system can automatically modify access levels according to the specific phase of collaboration and the nature of shared resources.

Inventive Principle:
Principle #35Parameter changes

2Ease of operation

If static RBAC roles are defined for access control, then permission management is simplified, but responsiveness to workflow changes deteriorates

Engineering Contradiction:
Improvepermission managementVSAvoidresponsiveness to workflow changes
Core Design Contradiction:
Ease of operationVSSpeed

Solution Approach 1:

The system enables self-service access control by automatically granting and revoking permissions based on workflow stage transitions. The workflow engine itself manages access control without requiring external intervention, making the system responsive to workflow changes while maintaining automated permission management.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system implements feedback mechanisms where workflow stage changes automatically trigger access control policy updates. The workflow engine monitors stage transitions and feeds this information back to the access control module, which then adjusts permissions accordingly, ensuring rapid response to workflow changes.

Inventive Principle:
Principle #23Feedback

3Adaptability or versatility

If RBAC roles are proliferated to cater to complex workflows, then access control granularity is improved, but system complexity deteriorates

Engineering Contradiction:
Improveaccess control granularityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments access control into workflow-stage-specific permissions rather than creating numerous RBAC roles. Each workflow stage has its own access control policy, allowing fine-grained control over shared resources without proliferating roles. This segmentation approach maintains granularity while reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system uses universal workflow participants and resource types that can function across multiple workflow stages. Instead of creating specialized roles for each scenario, the same participant and resource definitions are reused with different permission levels based on workflow context, reducing complexity while maintaining adaptability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Ease of manufacture

If RBAC is used for access control, then initial setup is simplified, but ability to protect business secrets in dynamic scenarios deteriorates

Engineering Contradiction:
Improveinitial setupVSAvoidprotection of business secrets
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The system performs preliminary definition of workflow stages, participants, and resources with associated access control policies. By pre-configuring the workflow structure and access rules for each stage, the system maintains ease of initial setup while ensuring that business secrets are protected through automated enforcement of stage-specific permissions during execution.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP4703942A1Workflow-aware access control for source code management
Publication Date: 2026.03.04 SIEMENS AG
  • EP4703942A1 patent drawingFigure 1
  • EP4703942A1 patent drawingFigure 2
  • EP4703942A1 patent drawingFigure 3

AI summary

Embodiments of the present disclosure provide a system and method for workflow-aware access control, WFAC, in a source code management, SCM, repository. The method may comprise: receiving, by a central manager, a request from a Resource Contributor, RC, to access the SCM repository owned by a Resource Owner, RO; initiating, by either the RO or the RC, a creation of an access policy for accessing the SCM repository; customizing, by the initiating party, a policy template using metadata to define specific contract details; deploying the customized access policy as a smart contract on a semi-private blockchain; obtaining agreement from the RO and the RC by collecting digital signatures on the smart contract; evaluating, by the central manager, one or more conditions specified in the agreed access policy; updating, by a controller, one or more SCM settings based on the evaluated conditions to grant the RC access to the SCM repository; and allowing, by the central manager, the RC to access the SCM repository in accordance with the updated SCM settings.