I have a MEAN Stack application hosted in Azure which targets users from different organizations. The Node API app is hosted as an App Service. When a user registers, I have to send a verification email to their email-id from a common email-id (like hello#contoso.com). I have an Office 365 Business custom email account for this purpose.
I googled a lot about this but most of the Microsoft documents are talking about using logged in user's credential to access Graph API ("me/sendMail"). I want to implement the email feature independent of logged in user. Please suggest a good design. Sample code will help me save time.
We can Use an authenticated SMTP relay service, which is known as a Smart Host, with TLS capability to deliver emails from Azure VMs or App services.
The most common SMTP relay service to integrate with Microsoft Azure is SendGrid.
For complete setup and more information please refer to this BLOG & SO THREAD
Related
This seems like it should be incredibly easy. But here I am on day 3 of reading blogs and watching youtube videos from India. Is this just not possible?
I have a LogicApp that has a system assigned identity. I used Powershell to create an identity in Exchange online based off of this identity and give the "Send As" permission to a shared mailbox. That part is done and I didn't get any errors and we've done the same thing for "actual code" projects that use "App Registrations" and the Microsoft.Graph library to send emails so I'm fairly confident it works.
I can't use an O365 connector in the LogicApp because that needs a user to login and create the connection. Then I'd have to give myself rights to "Send As" this mailbox which I don't want to do and seems like a terrible practice because one day I might leave the company, probably by stroke, but still my account might one day be gone.
Using the Microsoft Graph explorer and some documentation I can see that mail can be sent using the graph in what seems like a pretty straight forward way. I've verified, using the graph explorer that I can send mail as myself using that API.
Can I send email as a shared mailbox via the Microsoft Graph API using an Azure LogicApp? Even if I need to create an App Registration to do it, that's fine. I don't know how to tell the API to send send an email using a system assigned identity.
I agree with #Skin, you can use service account for authentication instead of user login.
I would suggest you to follow below steps, it may helps in achieving your requirement.
Create app registration for the logic app in active directory.
Use system managed identity as authentication for graph api.
Refer this link for managed identity for graph API.
Grant system-assigned identity of logic app as Send AS permission for shared mailbox.
In logic app send email action, use shared mailbox address
I don't know how to tell the API to send send an email using a system assigned identity.
There is no need to specify the system-assigned identity in the API call. When you use a system-assigned managed identity as authenticate with the Microsoft Graph API in your Logic App Http action, the identity is automatically passed to the API as part of the authentication process.
As shown in below image you can on System assigned identity in logic App.
Then in Http action take Post as method and mention Graph Api's URL and take managed identity as Authentication.
For me it is no more possible (by default) to send email with a shared email box, you have to use the same email than the one used to authenticate the account.
We use Azure Logic Apps that are deployed from DEV to TEST to PROD using powershell scripts. Thoe Logic Apps use API connections.
For certain API connections we want to use a different Service User instead of my personal account. So if a Logic App sends an E-Mail it should send it as Service User and not myself. The special thing about API connections is, that Azure forces you to re-authenticate them after deployment by powershell script. So after each deployment you need to re-authorize API connections.
I successfully managed to authenticate using powershell script with the sample mentioned here: https://github.com/logicappsio/LogicAppConnectionAuth
However, it will always somehow authorize me on with my Windows account. I am not able to log in as someone else. When the Azure Logon Window appears and I enter the service users name, but it will then not ask me for the passwort, it will authorize the connection with my personal user right after entering a username.
How can I use Azure powershell commands to perform connection authorization as a different user?
I was hoping someone could point me into a better direction (google keywords, etc.) on how to authorize API connection as a different user.
I understand your question is about authorizing API connections with different user account or service accounts. The behavior you specified above is specifically for office 365 connection. Authorization mechanism differs in different set of connectors.
However, for using service accounts to authorize Office 365 API connections, we need to make sure that browser cache doesn't use the Windows/Azure logon credentials automatically.
You can clear the browser cache and do the authorization from a private browser.
If that doesn't help you, there is a hack that's explained in this blog.
https://techcommunity.microsoft.com/t5/integrations-on-azure/using-service-account-for-office-365-outlook-connector/ba-p/1978513
Let me know if you have any questions.
Haris
I am trying to deploy my Azure Bot Service but I am kinda struggling to understand for what is Microsoft app ID and password used for? Can someone explain me these terms?
I was trying to find the answers online but unsuccessfully.
Thank you for any help.
This is the identity of the Bot Service.
You will notice in the App registrations of Azure Active Directory (AAD) that your Bot Service is in there. This is to give you the ability to Authenticate, Authorize and Audit (AAA) the Bot Service.
For example, you may want to provide access for your Bot Service to other services in your subscription, or other subscriptions also using the same AAD.
And so, the app has a set of credentials which it can use. The concept is similar to Managed Service Accounts in Windows Server.
The Microsoft app ID and Password are used to register the bot with the Azure Bot Service.
After you register it, those credentials will be used by the bot connector to authenticate the calls to your Bot's service and allow you to configure the bot with the different available channels.
Bot security is configured by the Microsoft App ID and Microsoft App Password that you obtain when you register your bot with the Bot Framework. These values are typically specified within the bot's configuration file and used to retrieve access tokens from the Microsoft Account service.
I have a Spring boot application run on Azure App Service, from which I want to send emails to users.
I can already do that with a gmail account I created myself, I just needed to turn on "allow less secure apps" feature.
However, I'm required to use another gmail account which belongs to a organization and thus is forced to use 2-step verification as per the organization policy.
Is it possible to complete the 2-step verification process from Azure's App service? What other options do I have?
Is it possible to complete the 2-step verification process from Azure's App service?
In short, we couldn't do that from Azure's App service directly with you gmail account.
From goolge document we could know
that 2-Step Verification adds an extra layer of security to your users' managed Google accounts by requiring them to enter a verification code in addition to their username and password when signing in to their account.
In your case, according to your organization policy the google account is forced to enable 2-Step Verification. Based on my understanding, we can't do from the Azure's App service directly.
What other options do I have?
Based on my experince, you could registry a SendGrid account with your organization gmail account. Then you could use sendgrid to send the email to other users. Then other users could get the email from the organization gmail account but maybe there is no sent mails in the organization gmail account. More detail please refer to How to Send Email Using SendGrid with Azure.
Note: I don't test it on my side.
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.