resource bound access control proposal

[Martin187187]

Motivation

The existing object-based Access Rule Model is very flexible, but for hierarchical AAS data it can become difficult to model and understand larger access-control configurations.

Today, access rules are defined first and their target resources are selected through OBJECTS:

Rule 1 -> OBJECTS -> Submodel A
Rule 2 -> OBJECTS -> Submodel A
Rule 3 -> OBJECTS -> SME X
Rule 4 -> OBJECTS -> Submodel B
...

To determine the policy of Submodel A, all Access Rules need to be considered to find the rules that reference this resource.

The resource-bound view turns this around:

Submodel A
  -> Access Rule Model
       -> Rule 1
       -> Rule 2

Submodel B
  -> Access Rule Model
       -> Rule 1

This makes access rules easier to model, understand and maintain, because all rules governing one resource are grouped together and the resource does not need to be repeated in every rule.

Natural fit for hierarchical AAS data

The AAS information model is inherently hierarchical:

AAS
  -> Submodel
       -> SubmodelElement
            -> nested SubmodelElement

Resource-bound policies can follow exactly the same structure.

For example, consider a TechnicalData Submodel that is generally readable by customers, except for one internal property:

TechnicalData
  Policy:
    Customer -> READ

  Manufacturer
    -> inherits TechnicalData policy

  SerialNumber
    -> inherits TechnicalData policy

  InternalProductionCost
    Policy:
      Manufacturer -> READ

Instead of explicitly assigning the customer rules to every individual SubmodelElement, the common policy can be defined once at the Submodel level. Only resources requiring different access rules need their own Resource-Bound Access Rule Model.

This keeps the security model close to the structure of the protected data and makes exceptions easy to identify.

Established access-control pattern

Scoping permissions to resources and applying permissions along a resource hierarchy is also a common pattern in existing access-control systems.

Examples include file-system ACLs, where permissions can be associated with an object and inherited by child objects, and cloud IAM systems, where permissions are assigned at a particular resource scope and can apply to resources below that scope.

The proposed resource-bound view applies the same general principle to the AAS hierarchy while keeping the existing ABAC concepts of Part 4.

Small Extension of the Existing Model

This does not require a new authorization mechanism.

The existing:

• ACLs and RIGHTS
• attributes
• formulas
• filters
• AAS object identifiers

remain unchanged.

The main structural difference is simply:

Current:

Access Rule -> OBJECTS -> Resource

versus:

Resource-bound:

Resource -> Access Rule Model -> Access Rules

The existing object-based representation remains available for use cases where a global rule-oriented view is more suitable.

The resource-bound representation therefore provides an additional, more natural way to model policies for hierarchical AAS data without replacing the existing model.