Allow nested paths for the message subject in a policy (message ressource)

[thomas-fries-keen]

Hi there,

we want to control authorization for messages that are allowed to be sent to a twin. A feature can receive all kinds and variants of messages and so we want to structure the messages. Fortunately the ditto REST API allows this. I can sent these kind of messages to a feature:

/features/CoffeeBrewer/inbox/messages/brew/espresso
/features/CoffeeBrewer/inbox/messages/brew/cappuccino

This issue is about to control access in the same way. It should be possible to grant access to message subjects with a nested path in the policy entry. Example:

...
"resources": {
        "thing:/": {
          "grant": [
            "READ",
            "WRITE"
          ],
          "revoke": []
        },
        "message:/features/CoffeeBrewer/inbox/messages/brew/espresso": {
          "grant": [
            "READ",
            "WRITE"
          ],
          "revoke": []
        }
      }
...

Should grant access to sent this message: message:/features/CoffeeBrewer/inbox/messages/brew/espresso
But not to sent this message: message:/features/CoffeeBrewer/inbox/messages/brew/cappuccino
It would be nice that policies allow nested paths on the messages like it is supported for the thing: ressource (see this documentation)

[thjaeckle]

Thanks for the request @thomas-fries-keen

a) Indeed it seems not supported to define "nested" message subjects in policies

• the current policy enforcement implementation does not seem to recognise it

b) I cannot reproduce what you reported that partial thing READ permissions are not filtering as expected

• there are even many integration tests which make sure that this behavior does not break

[thomas-fries-keen]

Thanks @thjaeckle for the quick response!

may I convert this to a feature request then? Does that fit to the concept or would that break things and be huge effort?

Reasoning would be

• consistency to the thing: ressource in a policy
• consistency with the HTTP API that supports nested message subjects

Background: we want to model fine grained policies for a feature that is representing another service that provides device related requests. In the example, the service would provide these ressources:

/brew/espresso
/brew/cappuccino
...

These services should not replicate their device data into the persistet twins, but we would like to apply the same authorization model for retrieving data and executing operations

[thjaeckle]

Sure, please go ahead and rephrase the question to a feature request - it does make sense when having that nesting on HTTP as requirement - I can think of reasons where needing this makes sense.