[5.48] Send Email Server Activity - Oauth support
Terminée
Introduced in VertiGIS Studio Workflow 5.48
The Send Email Server Activity in Workflow 5 only supports simple authentication SMTP AUTH for sending email via Office365.
Smtp auth is legacy and not compatible with Office365 Microsoft Security Defaults. Many IT security policies will block its use rendering the send email activity useless.
Microsofts recommended approach for Office365 is to use OAuth https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth.
Can you please upgrade the Send Email activity to add support for OAuth access tokens as an alternative authentication mode.
-
When using the Send Email activity, emails are intended to be sent using credentials that are stored on your own server and used by Workflow Server running on the same machine. OAuth would be more suited for when the end user needs to be authenticated with the mail server, if I understand correctly.
0 -
Owen Parfrey I've looked into this off and on over the last while. It's a bit of a complicated one as certain parts need to be achieved by configuring some Microsoft services in the cloud.
In your situation, could you help me understand which of these two scenarios seems closer to your use case?
a) The identity used to send the email is based on the current workflow user.
b) The identity used to send the email is configured ahead of time. It doesn't matter who is running the workflow.Also, do you have your own application registered in Microsoft Entra ID, or were you hoping this would be something we would provide?
0 -
Hi Ken,
For most of the use cases I have come across the identity would be configured ahead of time in the back-end server configuration - option B.
The expectation is that the user would have an existing and valid user configured in Entra. e.g. the client has a valid Office356 Organisation account and user and they what to configure a VS server Workflow such that it can send emails on behalf of that user. Typically, these would be admin style notifications or emails to distribution groups.
0 -
Hi Owen,
Thanks for those details. That's good news. This sounds like the simplest case from our perspective. I think we should be able to adapt the schema of the “C:\ProgramData\Geocortex\Workflow\emailsettings.json” file to accept the necessary details such as client_id. I'll look into it.
0 -
Ken Lyon has there been an update to this?
0 -
Dan Griffin This has been on the shelf for a while, unfortunately. While the code change itself is potentially quite trivial, we need to do a bit of work internally to be able to test it. I have sent a request to our IT department to help with this. Hopefully we can get moving on this soon.
0 -
Hi Ken,
We are still VERY keen to see this implemented as soon as you can arrange it. We have several customers who have had to implement workarounds due to the existing Send Email activity implementation not being suitable for their environment. If you need some assistance with external testing, we would be happy to assist.
0 -
Dan Griffin Owen Parfrey I'm happy to announce this will be in the upcoming Workflow 5.48 release.
It's going to be a bit of an “alpha” feature as we haven't yet been able to test it in our environment. However, I've added the necessary plumbing for you to be able to try it yourselves.
There are three new properties to add to the emailsettings.json file. (Default location: C:\ProgramData\Geocortex\Workflow)
- EmailSettings
- Configurations
- Default
- EntraTenantId
- EntraAppId
- EntraAppClientSecret
- Default
- Configurations
I'm only learning about the Entra and Azure configurations just now, but hopefully these terms are familiar to you. You should be able to find out the appropriate values for your organizations.
0 - EmailSettings
-
We got it working with the code that was merged, so it should work if you use the right values.
Here is what you will need in the Email Settings:
- Host: smtp.azurecomm.net
- Port: 587
- Username: An SMTP Username from Email > SMTP Usernames in Azure Communication Service. e.g. “exampleuser”
- Password: “” (Not sure if you can remove it entirely, but an empty string is ok.)
- EnableSSL: false (I think it automatically upgrades to TLS.)
- EntraAppId: The Application ID listed with the above SMTP Username. (This is a value like 99999999-9999-9999-9999-999999999999.)
- EntraAppClientSecret: A secret associated with the above Application ID. (I don't know the exact details but it needs to be configured to grant the necessary permissions.)
- EntraTenantId: The tenant that owns the Application ID above. (This is also a value like 99999999-9999-9999-9999-999999999999.)
The other important detail is the From input to the Send Email activity. The email address entered must be from a domain linked to the Tenant / Application in the configuration. In our case it was a MailFrom address from Azure Email Communication Services.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
9 commentaires