Not helpful: Using Managed Identity with Azure Communication Services

[jordanmills]

Section Using Managed Identity with Azure Communication Services makes no sense

It basically says to enable system assigned managed identity on an ACS resource, then give that identity access to the resource it represents. Maybe it means to grant some other managed identity access to the ACS resource, but it also does not say what access to grant. This should be rewritten for clarity and specify exactly what access to grant for what functionality.

Also the second to last sentence is a fragment that makes no sense. "Now that you have learned how to enable Managed Identity with Azure Communication Services."

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 0e659def-d112-d5d7-7112-03e0f33271dd
• Version Independent ID: ab4b80df-4ce1-dfb9-7334-964a7fa93e56
• Content: Azure Communication Services support for Managed Identity
• Content Source: articles/communication-services/how-tos/managed-identity.md
• Service: azure-communication-services
• GitHub Login: @Joeleniqs
• Microsoft Alias: joelen

[TPavanBalaji]

@jordanmills
Thanks for your feedback! We will investigate and update as appropriate.

[AjayKumar-MSFT]

Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

[ascott18]

Just submitted some feedback from the on-page feedback buttons on this. Its crazy how hard it is to figure out how to authenticate to this service with managed authentication. The fact that this page claims to be explaining this but is in fact describing the exact opposite (how to let ACS authenticate to other resources) is disappointing.

The real documentation for this is nested under the SMTP articles for some reason. https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email-smtp/smtp-authentication#creating-a-custom-email-role-for-the-microsoft-entra-application

Tucked away in this article is the fact that you need to assign the "Contributor" privileged admin role to principals that need to send email, which is kind of crazy in and of itself - why is there not a built-in role that grants email-sending permissions? I don't think I've ever seen any other Azure service where the official instructions for granting the most basic usage permission of a resource starts out with "here's how to create custom roles in azure".

[ascott18]

Related: #109461

[jordanmills]

Just submitted some feedback from the on-page feedback buttons on this. Its crazy how hard it is to figure out how to authenticate to this service with managed authentication. The fact that this page claims to be explaining this but is in fact describing the exact opposite (how to let ACS authenticate to other resources) is disappointing.

The real documentation for this is nested under the SMTP articles for some reason. https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email-smtp/smtp-authentication#creating-a-custom-email-role-for-the-microsoft-entra-application

Tucked away in this article is the fact that you need to assign the "Contributor" privileged admin role to principals that need to send email, which is kind of crazy in and of itself - why is there not a built-in role that grants email-sending permissions? I don't think I've ever seen any other Azure service where the official instructions for granting the most basic usage permission of a resource starts out with "here's how to create custom roles in azure".

Thank you, that definitely helps. Or at least demonstrates the futility. That's the kind of thing that should be a data plane action. There's no world where it's okay to give a client application full control of a resource it needs to use for a specific purpose. How am I supposed to take any of this seriously when least operating privilege isn't even an afterthought?