Support setting customSecurityAttributes to Microsoft.Graph/servicePrincipals

[dkershaw10]

Bicep version
0.36.1

Resource and API version
0.2.0-preview beta and v1.0

Auth flow
Doesn't matter

Describe the bug
I want to update a service principal resource with some custom security attributes (CSAs).
However, there's no Bicep examples of how to do this and IntelliSense doesn't seem to know about CSAs and I see it's missing from the Bicep types definition.

Additional context
The Microsoft.Graph/servicePrincipals Bicep type does not specify a CSA. There isn't currently a way to support customSecurityAttributes in the Bicep type definition, as the underlying Microsoft Graph type is an open type with dynamic schema. That said, the customSecurityAttributes property can be defined in the Bicep template file (although the Bicep extension will warn that this is an unknown property). The template could in theory also be deployed, as the Graph Bicep extension will passthrough unknown properties to Microsoft Graph.

However, the deployment still fails with a 403 Forbidden, as the Graph Bicep extension currently doesn't have the necessary permissions to read and write CSAs.

[dkershaw10]

Let's look into adding the requisite delegated permission.

[slavizh]

I was about to just try to test and implement this but I got e-mail notification about this thread and this will save me some time of testing as I will not have to implement it currently due to not working. One update though the customSecurityAttributes is now on the resource type. The structure of the property is explained here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/custom-security-attributes-apps?pivots=ms-powershell. Not sure why the property is of type any() for me it should be an object of key value pairs where the name of the key can be any (*) and the value is object. The values inside that object seems highly depend on what is configured and they differ (with exception of @odata.type which it seems it is always required) so leaving the value as open object might be the best in terms of how the schema should define the property. But of course may be customSecurityAttributes is automatically generated and it cannot have different schema.

[dkershaw10]

Yes - it's in the type definition and we'll look at whether it should be defined as an object.
In OData it's defined and an open type, and I believe OData can infer the type of the properties in the CSA. The extra property annotation is to indicate whether the property is a collection/array rather than single-valued.

In terms of the type definition, I think we also wanted to investigate whether we could do something with a custom CSA Bicep type natively that doesn't require authors to have to know about OData syntax (like @odata.type or property instance annotations like 'Project@odata.type': '#Collection(String)'). The fact that you need to "escape" the special @ character by putting the property name in quotes is also a bit nasty.

So...

1. "Good": add the delegated permission that the extension requires and rely on passing through any unknown properties (under CSA), including properties with the @ character. i.e. unblock the scenario.
2. "Better": have a dedicated Bicep type for CSA that doesn't leak any OData syntax for an improved authoring experience.

[slavizh]

Note that there for Azure resources there are properties that require putting them in single quotes so it is not so that uncommon and not a big deal.