[Feature Request]: `Microsoft.Web/Connections` - Add support for undocumented `parameterValueType`, `parameterValueSet`

[coolhome]

Description

Add support for Single-Authentication and Multi-Authentication for Microsoft.Web/Connections.

Documentation Reference:

• https://learn.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity?tabs=consumption#single-authentication
• https://learn.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity?tabs=consumption#multi-authentication

Real Examples:

• Single-Authentication - https://github.com/Azure/SET/blob/597469375e93a3d0c946db9d56505a528220966a/Content/Azure%20Data%20Manager%20for%20Energy/Solutions/Azure%20AD/Sync%20Entitlements/src/logicapp.bicep#L14-L26
• Multi-Authentication - https://github.com/microsoft/Azure-Secure-Enclave-for-Research/blob/897feb157ada620c1660021020bfeed170c5d5ee/Bicep/child_modules/logicApp.bicep#L39-L58

Missing Specification Tickets:

• https://github.com/Azure/azure-rest-api-specs/issues/19459
• https://github.com/Azure/azure-rest-api-specs/issues/20851
• https://github.com/Azure/bicep-types-az/issues/1490
• https://github.com/Azure/bicep-types-az/issues/1501
• https://github.com/Azure/bicep-types-az/issues/1671
• https://github.com/Azure/bicep-types-az/issues/1662
• https://github.com/hashicorp/terraform-provider-azurerm/issues/23064

[rahalan]

@coolhome do you need more documentation or an implementation? In case of the second, can you participate in writing those? Thanks, Rainer

[coolhome]

@rahalan I would like to contribute towards a better implementation to make the current module more useful. The lack of typing mixed with unpublished preview api makes me nervous.

I'm still in the very early stages of figuring out what is needed. Here is my current state if you would like to review and give me any tips/suggestions.

https://github.com/coolhome/ResourceModules/commit/86a530d5b7c170c6913473709632c806c3b12834#diff-e59fe3e95d066bc83057705d46408f57c9f8b6f13ebb38aa64f05441cadf1064

[chris-w-dev]

@rahalan I would like to contribute towards a better implementation to make the current module more useful. The lack of typing mixed with unpublished preview api makes me nervous.

I'm still in the very early stages of figuring out what is needed. Here is my current state if you would like to review and give me any tips/suggestions.

coolhome@86a530d#diff-e59fe3e95d066bc83057705d46408f57c9f8b6f13ebb38aa64f05441cadf1064

Why not make it a bit more straightforward and just expose each of the properties as separate parameters? Then consumers of this module are in control of what settings to specify. There is a lot of variety in the configurations of different connectors, so I can even imagine people using this module as a building block for modules dedicated to a Service Bus or Storage connection.

For example:

1. Let parameter kind accept V1 and V2 values, so that its value can be assigned directly. If the usage of V1 ever changes, this module would not have to be modified.
2. Provide separate parameters for alternativeParameterValues, parameterValueSet and parameterValues and use a construction like !empty(<parameter>) ? <parameter> : null for each of them in the resource definition.
3. Set property parameterValueType to Alternative when parameter alternativeParameterValues is not empty; otherwise set it to null.

Some additional ideas:

• Disable warnings for BCP187 and BCP089 for kind and parameterValueSet. Otherwise build warnings would occur when people start using this module.
• Afaik, parameter api always has only a property id that points to the subscription resource ID of the connector. Is it not possible to change that parameter to a string and use its value for that id property? Or is there another reason why it is an object?

I haven't tested this, so I'm not sure if there will be any problems with this approach. Just my 2 cents.