feat: mqtt-style resource wildcard matching

[jcosentino11]

Issue #, if available:

Description of changes:

Proposes a new configuration option, enableMqttWildcardEvaluation, to allow policy resources to be evaluated using MQTT wildcard.

e.g.

       policies:
          thingAccessPolicy:
            subscribe:
              statementDescription: "mqtt subscribe"
              operations:
                - "mqtt:subscribe"
              resources:
                - "mqtt:topic:${iot:Connection.Thing.ThingName}/+/test/#"

Allows client devices to subscribe to thingName/path/test/path1/path2, for example

Why is this change necessary:

How was this change tested:

Any additional information or context required to review the change:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[MikeDombo]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

[github-actions]

Code Coverage Report

File	Coverage
All files	74%	✅

Minimum allowed coverage is 50%

Generated by 🐒 cobertura-action against 6b156de

[jcosentino11]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

Ah I see https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html now, looks like ? is used for pseduo-+ matching

[MikeDombo]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

Ah I see https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html now, looks like ? is used for pseduo-+ matching

Well yeah, but that's for IPC which isn't MQTT :)
So.... reasons, but maybe not good reasons.

[github-actions]

Benchmark Results

Benchmark	Score
com.aws.greengrass.clientdevices.auth.benchmark.AuthorizationBenchmarks.GIVEN_policy_with_thing_name_variable_WHEN_auth_request_THEN_successful_auth	1256388.94 ops/s
com.aws.greengrass.clientdevices.auth.benchmark.AuthorizationBenchmarks.GIVEN_policy_with_wildcards_WHEN_auth_request_THEN_successful_auth	221451.01 ops/s
com.aws.greengrass.clientdevices.auth.benchmark.AuthorizationBenchmarks.GIVEN_single_group_permission_WHEN_simple_auth_request_THEN_successful_auth	2539896.74 ops/s

[jcosentino11]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

Ah I see https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html now, looks like ? is used for pseduo-+ matching

Well yeah, but that's for IPC which isn't MQTT :) So.... reasons, but maybe not good reasons.

Should be for MQTT/HTTP/Websockets? IoT Core publish/subscribe, unless im missing something here

[MikeDombo]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

Ah I see https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html now, looks like ? is used for pseduo-+ matching

Well yeah, but that's for IPC which isn't MQTT :) So.... reasons, but maybe not good reasons.

Should be for MQTT/HTTP/Websockets? IoT Core publish/subscribe, unless im missing something here

Not too sure what you mean. I made the IPC policy more lenient to avoid common customer misunderstandings when compared with V1. But we wanted to keep CDA aligned with IoT Core as much as possible.

[jcosentino11]

This was purposefully not included because it will differ from how IoT Core works. If you have permission to subscribe to A/# then you have permission to subscribe to that and exactly that.

Ah I see https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html now, looks like ? is used for pseduo-+ matching

Well yeah, but that's for IPC which isn't MQTT :) So.... reasons, but maybe not good reasons.

Should be for MQTT/HTTP/Websockets? IoT Core publish/subscribe, unless im missing something here

Not too sure what you mean. I made the IPC policy more lenient to avoid common customer misunderstandings when compared with V1. But we wanted to keep CDA aligned with IoT Core as much as possible.

I think we're talking about two different things 😅 Was saying that https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html and ? matching is IoT Core specific

[MikeDombo]

Switching comment to threads to make it more sane.

My point is that IoT Core for MQTT policies does not let you subscribe to A/B when the policy is A/#. Greengrass PubSub does allow this, but CDA does not in order to match the behavior of IoT Core.

[jcosentino11]

Okay yeah I understand your point now. So to have parity with IoT Core then, ? single char matching would be needed, so then CDA knows about * and ?

[MikeDombo]

Yeah guess so, if iot core just added that in.

[MikeDombo]

But wildcards # and + shouldn't change the way they currently work.

[jcosentino11]

Yep will either close or revise this. Reason it came up was customer ask so was exploring the idea

[jcosentino11]

Closing in favor of ? matching: #437