I think you can reach your end goal, but maybe not using either of the options you've described.
You are correct that AAD Provisioning doesn't support custom complex-typed, multi-value or referential attributes. When you mention an array of key:value pairs, that isn't a thing when it comes to attribute data types in SCIM. What aligns with that the closest in the SCIM spec is a complex-typed attribute.
One thing to note - for complex attributes, the sub-attributes must be defined in the schema, so a complex attribute would only work if all of the sub-attributes ("keys") were fixed and already known ahead of time rather than being defined dynamically.
What exactly you'd be representing with the keys isn't clear, but if this was possible with AAD Provisioning a few approaches are outlined below.
Custom single-valued complex attribute:
"customAttribute": {
"subAttribute1":"value1",
"subAttribute2":"value2",
"subAttribute3":"value3"
}
Custom multi-valued complex attribute:
"customAttribute": [ {
"subAttribute1":"value1",
"subAttribute2":"value2"
},
{
"subAttribute1":"value1",
"subAttribute2":"value2"
}
]
Custom multi-valued string attribute:
"customAttribute": [
"value1",
"value2",
"value3"
]
UNFORTUNATELY.. custom complex and/or multi-valued attributes aren't supported today. If you have your data source figured out already - one or more attributes on the user object in Azure AD presumably - then there are a few approaches with one or more single-valued string attributes that may work, such as:
One custom single-valued string attribute with comma delimited values:
"customAttribute":"value1,value2,value3"
Multiple custom single-valued attributes, each containing a single value (useful for something like "Division 1" and "Division 2" attributes)
"customAttribute1":"value1",
"customattribute2":"value2"