PolicyDefinition unmarshalling fails when metadata.AssignPermissions is stored as string instead of boolean

[jaimeyh]

Bug Report

• Import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resources/armpolicy
• SDK version:
  • github.com/Azure/azure-sdk-for-go/sdk/azcore v1.18.2
  • github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/resources/armpolicy v0.10.0
• Output of go version: go version go1.24.5

What happened?

When retrieving a PolicyDefinition using the Azure SDK for Go, an unmarshalling error occurs if the metadata.AssignPermissions parameter is stored as a string ("true" or "false") instead of as a boolean (true or false).

Error trace: Azure error PolicyDefinitions; error: ","err":"unmarshalling type *armpolicy.DefinitionListResult: unmarshalling type *armpolicy.ParameterDefinitionsValueMetadata: struct field AssignPermissions: json: cannot unmarshal string into Go value of type bool

Although Azure documentation and the Azure Portal indicate that AssignPermissions is a boolean, the Azure Portal and az CLI allow saving the value as a quoted string.

When the value is stored as a string, the az CLI returns the raw resource and shows the boolean in quotes without issue. However, when retrieving it through the SDK, the deserializer expects a boolean, which causes an unmarshalling error.

What did you expect or want to happen?

The SDK should be able to robustly handle the metadata.AssignPermissions field regardless of whether it is stored as a boolean or as a string, or Azure should prevent saving it as a string if the expected type is boolean.

How can we reproduce it?

In the Azure Portal, create or edit a PolicyDefinition in JSON format and set in metadata the key "AssignPermissions" as a string, for example:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": "[parameters('allowedLocations')]"
      }
    },
    "then": {
      "effect": "audit"
    }
  },
  "parameters": {
    "allowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of allowed locations for resources.",
        "displayName": "Allowed locations",
        "strongType": "location",
        "assignPermissions": "true"
      }
    }
  }
}

Anything we should know about your environment.

The problem happens only when deserializing the resource via the Azure Go SDK.

[jhendrixMSFT]

Looks like incorrect OpenAPI definition.

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/resources/resource-manager/Microsoft.Authorization/stable/2023-04-01/policyDefinitions.json#L616-L619

[jaimeyh]

Thanks for your reply. I would like to clarify:

The OpenAPI definition (assignPermissions as boolean) looks correct to me.

The real problem is that the Azure Portal and az CLI allow saving arbitrary values as strings for this field. For example, I was able to set "assignPermissions": "tomato" and the API accepted it without any validation.

Once this invalid value is stored, retrieving the PolicyDefinition through the Go SDK fails, because the SDK expects a bool (as per the OpenAPI contract) and cannot unmarshal a string.

So I believe the issue is not with the OpenAPI spec, but with the backend/portal not enforcing type validation when saving the resource.

Would it make sense to enforce the validation at the API level (reject non-boolean values for assignPermissions), so that the SDKs can remain strongly typed and aligned with the spec?