Add binding support for Azure Email Communication Service

[cilerler]

I would like to request the addition of a new component binding for the Azure Email Communication Service within the Dapr ecosystem. The objective is to facilitate applications using Dapr to seamlessly integrate email sending functionalities through Azure’s robust service.

[berndverst]

@cilerler can you explain a little bit more which functionality you need? I would assume you'd provide the name of an already created Azure Email Communication Service and we authenticate with that somehow, then you issue the binding command to send an email?

Unfortunately there is no Go SDK it seems - so we'd have to manually implement REST APIs which is not ideal. My preference would be to wait for a suitable Go SDK before implementing this.

[berndverst]

I see two APIs:

• Send: https://learn.microsoft.com/en-us/rest/api/communication/dataplane/email/send?view=rest-communication-dataplane-2023-03-31&tabs=HTTP
• Get Send Result: https://learn.microsoft.com/en-us/rest/api/communication/dataplane/email/get-send-result?view=rest-communication-dataplane-2023-03-31&tabs=HTTP

Would that be sufficient?

In general we only implement dataplane operations - so the Azure Communications resource would already need to exist.

Seems there will also be some custom code requires to provide the correct Authorization value as defined here: https://learn.microsoft.com/en-us/rest/api/communication/authentication?view=rest-communication-dataplane-2023-03-31

We'd have to find a way to leverage our existing Azure component authentication code as well: https://github.com/dapr/components-contrib/blob/main/internal/authentication/azure/auth.go

[cilerler]

@berndverst, you're absolutely correct about each point.

1. There is no Go SDK, so the REST API is the way
2. Only two values are required: ENDPOINT and KEY (for authentication)
3. Those API docs fulfill the requirements
4. Indeed, as with any other component (like Azure Configuration), the resource must pre-exist

Thanks in advance 🤗

[berndverst]

2. Only two values are required: ENDPOINT and KEY (for authentication)

@cilerler it says the AUTHENTICATION value is:

An authentication string containing a signature generated using HMAC-SHA256 scheme.

Right - it seems the access key is all that is required to sign the request to generate the HMAC token.

For managed identity based authentication is a bit more complicated.

Given how our code works I think this means we need to write custom code to obtain the credentials for a given identity.

Of course we would not want to implement this functionality without supporting managed identities (or workload identities) at the same time since that is the preferred authentication approach for Azure services.

I'll also try to ask the Azure Communications team what their plans for a GO SDK are.