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
Related
Right now I am trying to figure out whether it is possible at all to create a connection with a Service Account within bicep/an ARM template for connecting to Sharepoint in LogicApp.
This Service Account is a Microsoft account, but once I try to connect in the 'When an item is created' trigger I get a 'sign in to your account' auth prompt, where I have to specify the service accounts' username and password.
I can imagine that this would cause trouble when creating the connection from Bicep and/or an ARM-template, since the manual step of the auth window won't be performed there.
Is there anyway this can become possible, or is the infrastructure as code not possible for this?
Also, I see a 'connect via on-premises data gateway' option, might this be a viable alternative that is actually specifiable in ARM/Bicep should the authentication with a service account not be?
Sharing the same discussion here
At the moment, the sharepoint authorization works with the OAuth 2.0 Authorization Code Grant Type, which means, you can only get the authorization code by getting the user sign in to get the code. This behavior of the API is by design. Thus, there is no way to fully automate this.
Consider not re-creating api connection after initial manual authentication since there's no need unless cred changes, and only include logic apps in arm template for subsequent deployment.
Consider using HTTP with MSI to call graph API directly.
For connection resource define you can refer to this.
More details: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-deploy-azure-resource-manager-templates#authorize-oauth-connections
I am designing my first dev tool with the Azure SDK (JavaScript), and I am having a difficult time understanding how to authenticate users in production so the dev tool can access the user's Azure account. The tool is going to retrieve metrics from all of the user's Azure Functions in their tenant to display React component graphs based on those metrics over time. The app will be run locally with an npm run command.
My entry point for using Azure Identity in my app was this blog post (https://devblogs.microsoft.com/azure-sdk/authentication-and-the-azure-sdk/). I like the way the DefaultAzureCredential is working in development, using the tenant for whichever developer is running it by using the AzureCliCredential. I want a similar functionality for production, but for the browser instead of Azure Cli. In other words, if a user is already logged in to Azure Portal, it will get a credential for their tenant. How do I go about this?
One of the things I tried was opting into the Interactive Browser of the DefaultAzureCredential as described in that blog post. But even though, I could see the browser method in the src (https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/defaultAzureCredential.browser.ts), I couldn't figure how to opt into this when using the actual SDK. I couldn't find that method in the npm package in Azure Identity, and the documentation (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/defaultazurecredentialoptions?view=azure-node-latest) didn't help me either. If this is the correct option for my use case, I would like to understand how to opt into it and use it.
Another thing I tried was implementing the InteractiveBrowserCredential. As long as I pass in a redirectUri with a port not already being used by my app, it did open another tab to tell me to login to the Azure Portal if I am not already logged in. This is exactly the user experience I would want in my app. However, after logging in the credential didn't actually do anything. The credential returned actually has a client Id equal to the application Id (04b07795-8ddb-461a-bbee-02f9e1bf7b46) of Azure CLI (https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in) for some reason. This led me to look into the Interactive Browser Credential and find out that it is using the Authorization Code Flow (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/interactivebrowsercredential?view=azure-node-latest). This flow doesn't seem right for my use case, since I have to register my app. I am not trying to grant users access to my app, but access to their own Azure account. Is InteractiveBrowserCredential what I should be using?
Next, I looked into all of the different authentication flows. None of them seem quite right for my use case though. The closest one I found was the client credentials flow (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow) since I am authenticating the user to their own Azure account and not my app. However, even this one doesn't seem quite right because when I looked up how to implement that flow with Azure Identity (https://github.com/Azure/azure-sdk-for-js/blob/main/documentation/using-azure-identity.md#clientsecretcredential-and-clientcertificatecredential) I found out that I have to pass in the tenant Id. But the app won't know the user's tenant Id of the user before they log in. Which flow is right for this use case?
It seems like there is a gap in my understanding. How can I use the Azure SDK to implement an authentication flow that authenticates the user to their own Azure tenant (not authenticates them to my app) through the browser?
Thank you ShwetaMathur for answering this question in Q & A. Posting the same here to help Stack Overflow community members.
To access your application by Azure AD users, your application should also need to register in Azure AD.
Once your application is register, you can acquire the access token based on different OAuth flows which is needed to call various resources(Users in your case) or protected API based on your scenario.
Azure Identity TokenCredential provide various flows to obtain an access token based on different scenarios.
InteractiveBrowserCredential is one way to launches the system default browser to interactively authenticate a user and obtain an access token.
Using access token, you can retrieve user’s info or access any other resource in Azure tenant. The InteractiveBrowserCredential uses Authorization Code Flow to authenticate users for browser based applications and to access resources further.
Client credential flow is OAuth flow commonly used for server-to-server interactions that usually run in the background, without immediate interaction with a user and help to acquire the token and call protected web APIs.
Complete reference
I've setup single sign-on within Salesforce using Microsoft Azure. I've done this within the Setup > Settings > Identity > Single Sign-On Settings configuration menu by following the official tutorial from Microsoft. I'm successfully able to log into Salesforce using a user account in my Azure Active Directory, with just-in time provisioning enabled.
I'd like to be able to use the signed in user to then authenticate further requests to different Azure APIs, such as Azure blob storage. Is this possible using this configuration?
My assumption is that during the single sign-on process, Azure is returning some form of code or token to Salesforce which I can then use in future requests to obtain an authentication token for a specific API request. However, I'm not clear on how or where I'd access this code/token (or whether my assumption is actually correct).
When I was on the Salesforce end of AAD integration I didn't see anything that would look like session id but then again I'm not Azure guy. Might be something my client disabled.
If you followed that guide SF probably generated for you a sample Apex class for just-in-time (JIT) handling of logins and creating/updating users based on data it got from AAD.
You could edit this class, sprinkle some System.debug(JSON.serializePretty(attributes)); to see what AAD sent in the SAML assertion. (Or the assertion itself but it'll be base64-encoded from what I remember). Your SF admin will know how to add debug logging to the user you nominated as system user (who this code will be executed as).
See also https://stackoverflow.com/a/63992670/313628 and https://stackoverflow.com/a/58965058/313628
I have search and could not find anything specifically relating to my issue.
My client made changes last week with regards to service accounts etc after a malware attack.
Now my software does not authenticate via A.D. accounts anymore.
I used a little A.D. login test app to test and get the following when I attempt to login:
Credential Required
When I "allow" it logs in fine and again for rest of the session but upon restart same happens.
No, my software uses a Windows Service (c#) to authenticate users. This service logs in using a service account. The IIS application pools also use this same service account. All works fine except for the A.D. logins.
Microsoft has a FindPrivateKey sample with which you can apparently find the mentioned private key file and then to use the cacls.exe tool to give the services access to the private key file.
Is this sufficient? Does it have an effect if I do not login as the service account as it does not allow interactive login?
As the mentioned https://github.com/jasonjoh/node-tutorial example is a web app.
but i want to use it as a web service for example :-
i want to run this app on one machine(on server) and other apps made in(mobile apps, desktop and web app) could implemented or consume this services.
once user consume it my service would return [https://login.microsoftonline.com/common/oauth2/authorize?redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fauthorize&response_type=code&client_id=9892b97f-0026-4t3f-aa4f-5cb2olpdee7e]
then this url will be open in user's device/machine browser, then user could enter his/her office 365 credentials and once he clicked on SignIn it should aging come in web service and then it authorize the user using access token which is stored on server in cookies and then get/read emails from user office 365 account.
so please suggest me is it a possible scenario ? or if you have any alternate way to do this please let me know.
Thanks in Advance
Yes, this could work. You would need a web front end for the user to sign in, but you could then use the access token from a web service. Another alternative, assuming what you mean by web service, is to run in an unattended fashion by using the client credential OAuth flow, which allows an organizational admin to grant access to all mailboxes.