Grant Graph API Permission to Managed Identity Object
Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. We can access Graph API either using service principal object in Azure or using Managed Identity. When it comes to service Principal, we can grant API Permissions to the service principal object in Azure but incase of Managed Identity, we do not have option to provide Graph API permission for Managed Identity object via portal. Hence we need to use the below PowerShell script to grant Graph API Permission (Application Permission) to the managed Identity object. In this blog, we will see how to grant graph API permission to the Managed Identity object Note: To provide Graph API Permission you need to be Global Administrator in Azure Active Directory Below Parameters needs to be modified as per your resources: TenantID : Provide the tenantID of your subscription GraphAppId : This parameter is optional. We don’t have to change this value. This corresponds to Graph API Guid. DisplayNameofMSI : Provide your Logic App name. Since managed identity will be created in the same name as the resource on which identity is enabled, we can provide the Logic App name Permissions : Provide the appropriate Graph API Permission. https://docs.microsoft.com/en-us/graph/permissions-reference. Note: These are application permission. Powershell Script: $TenantID="provide the tenant ID" $GraphAppId = "00000003-0000-0000-c000-000000000000" $DisplayNameOfMSI="Provide the Logic App name" $PermissionName = "Directory.Read.All" # Install the module Install-Module AzureAD Connect-AzureAD -TenantId $TenantID $MSI = (Get-AzureADServicePrincipal -Filter "displayName eq '$DisplayNameOfMSI'") Start-Sleep -Seconds 10 $GraphServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$GraphAppId'" $AppRole = $GraphServicePrincipal.AppRoles | ` Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"} New-AzureAdServiceAppRoleAssignment -ObjectId $MSI.ObjectId -PrincipalId $MSI.ObjectId ` -ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole.Id Logic App: Execute the Powershell script to grant appropriate Graph API Permission to the Managed Identity object Once the Powershell is executed, you will be able to see the below Graph API permission added.
How to create API connection (Logic App consumption) using ARM REST API
As we know, we can deploy Logic App connector API connection using different ways, like via ARM template in Azure CLI, Powershell or DevOps. In some scenarios, customer may want to automate the API connection creation using API calls which cannot perform interactive thing (like login with the credentials). The process described in the following article shows step-by-step guide to create API connection for a Logic App connector (consumption) using ARM REST API with client like Postman.Deploying Standard Logic App to Storage Account behind Firewall using Service or Private Endpoints
Standard LogicApp is powered by new Azure single-tenant LogicApp runtime. Single-tenant Logic App offering runs as an extension on top of Azure Function runtime. Like Azure Functions, the standard Logic App leverages storage account services such as blob, File Share, Queue and Table for various purposes. For instance, the website content is stored in File Share which will be accessed by Logic App site for up and running. You can refer to this blog to understand how the storage services are leveraged in standard Logic App. In this article, we will see how to access the Storage account services on secured network using Service endpoints (or) Private Endpoints from Standard Logic App. By default, the portal creation experience of the Logic Apps expects the storage account must be accessible on public endpoint. Let us explore the below options on how to access the storage account over a secured network. Deploy Logic App standard resource having secured access to Storage account using Portal: Storage account need to be accessible on Public Endpoint i.e. Network access set to 'All Networks'. Create a Logic App resource, selecting the above created storage account during Logic App creation process. Enable the Service Endpoint or Private Endpoints (for all services i.e. blob, table, file, queue) on the storage account. Enable the VNET integration for Logic App resource with respective VNET and subnet have access to Storage account on Service Endpoint (SE) or Private Endpoints (PE). Set the below configuration settings (app settings) to access the storage on SE or PE’s. S.No Configuration Setting Value Comments Mandatory 1 WEBSITE_VNET_ROUTE_ALL (Legacy Setting and have new toggle button 'Route All' in networking tab) 1 It is legacy setting to route all outbound traffic through integrated subnet. There is new Route all toggle button available in the VNET integration blade. You can use either of these. If you don't set either of above and have VNET integration only private traffic will be going through your subnet and remaining will be through internet. Yes (Either Vnetruouteall setting in VNET blade or this setting in Environment variables) 2 WEBSITE_DNS_SERVER 168.63.129.16 (or) Custom DNS server IP Address It is to enforce Logic App to use specific DNS server. If its required you can set or else Logic App will use whatever the DNS servers configured on the integrated VNET. No 3 WEBSITE_CONTENTOVERVNET 1 It enables Logic App resource to access the website content over VNET traffic i.e. on SE or PE’s. Yes 4 WEBSITE_DNS_ALT_SERVER Alternate DNS server IP address It is to enforce Logic App to use specific DNS server while WEBSITE_DNS_SERVER unable to resolve. If its required you can set or else Logic App will use whatever the DNS servers configured on the integrated VNET. No No need to restart the Logic App site when you update any app settings or adding new workflows, Logic App gracefully restarts in an incremental mode without impacting any existing runs. However, it isn't suggested to make changes when there are any in-process transactions. Change the storage account network settings to selected networks Logic App may experience some interruption as the connectivity switch between public and private endpoints may take some time and you may not see workflows for sometime. You may restart the Logic App and wait for few mins and check whether workflows are loading or not. Deploy Logic App standard resource having secured access to Storage account using automated deployment tools: You can overcome the issue of exposing the storage account to public internet with the portal creation experience using ARM template deployment. With ARM deployment, you no need to open it for all Networks and can be deployed directly with Service endpoints or Private Endpoints. If you would like to deploy Standard Logic App to secure storage account from automated tools such as DevOps using ARM templates. You can refer to the sample templates available in the below Git-Hub. VeeraMS/LogicApp-deployment-with-Secure-Storage: Deploying Logic App standard resource with Storage account having Private endpoints (github.com) Note: When you are using Automated deployment tools, you must make sure FileShare is created in Storage account prior to the LogicApp template deployment and referred the same in Logic App config/app setting (WEBSITE_CONTENTSHARE). Below GIF's provides a glimpse on how to configure the Logic App to access storage account using Service or Private endpoints. Access over Storage Service Endpoint: Access over Storage Private Endpoints: Note: vnetRouteAllEnabled app setting is replaces, overrides and takes precedence over the legacy setting WEBSITE_VNET_ROUTE_ALL. Common Errors when Storage account is behind Firewall: We generally observe the below common errors when deployment storage account is behind firewall which indicates that Logic App is unable to access the storage account services. Access to host.json is denied: System.Private.CoreLib: Access to the path 'C:\\home\\site\\wwwroot\\host.json' is denied. Unable to load workflows in Logic App: You may observe that workflows are not visible in the Logic App while Storage access is changed to selected networks or Private Endpoints. You can check the browser logs and it may show below error. {"Code":"BadRequest","Message":"Encountered an error (ServiceUnavailable) from host runtime.","Target":null,"Details": [{"Message":"Encountered an error (ServiceUnavailable) from host runtime."},{"Code":"BadRequest"},{"ErrorEntity": {"Code":"BadRequest","Message":"Encountered an error (ServiceUnavailable) from host runtime."}}],"Innererror":null} Troubleshooting common errors: Make sure Storage account endpoints are reachable from Logic App VNET over 443 and 445 for respective endpoints. Validate the below if you are able to load the Kudu console of the LogicApp: Check name resolver command to make sure Storage endpoints are resolved to expected Ip addresses (Private (Private Endpoints)/Public (Service Endpoint or Public endpoint)). To validate this you can run below commands. nameresolver {StorageaccountName}.blob.core.windows.net nameresolver {StorageaccountName}.file.core.windows.net nameresolver {StorageaccountName}.queue.core.windows.net nameresolver {StorageaccountName}.table.core.windows.net Note: Avoid using nslookup in Kudu which by default uses the azure default DNS IP and wont use Custom DNS server if any if any configured at VNET or Appsetting. Validate the reachability of storage endpoints over 443 and 445 for respective services. tcpping {StorageaccountName}.blob.core.windows.net:443 tcpping {StorageaccountName}.file.core.windows.net:445 tcpping {StorageaccountName}.queue.core.windows.net:443 tcpping {StorageaccountName}.table.core.windows.net:443 If Kudu console itself not loading and have the errors, follow below troubleshooting steps: We can’t troubleshoot the above common errors from the kudu console when the Logic App site itself isn’t up or working . You can use the below to troubleshoot the access to the storage account services. Create an Azure VM with in the same Logic App integrated VNET, it can be a different subnet. The simpler test can be accessing the Storage account services using the Storage explorer tool. If any issues in connectivity using this tool, continue with the below steps. Check nslookup in the command prompt and make sure that the storage services are resolvable to intended IP addresses. If its on Service Endpoint, it should resolve to Public IP and if it has Private Endpoints, verify all services are resolvable to respective NIC private IP addresses. nslookup [StorageaccountHostName] [OptionalDNSServer] Verify for all storage services: nslookup {StorageaccountName}.blob.core.windows.net nslookup {StorageaccountName}.file.core.windows.net nslookup {StorageaccountName}.queue.core.windows.net nslookup {StorageaccountName}.table.core.windows.net If the DNS queries are resolvable, we can check psping or tcpping to storage account over 443 port. psping [StorageaccountHostName] [Port] [OptionalDNSServer] Verify for all storage services: psping {StorageaccountName}.blob.core.windows.net:443 psping {StorageaccountName}.file.core.windows.net:445 psping {StorageaccountName}.queue.core.windows.net:443 psping {StorageaccountName}.table.core.windows.net:443 If it is resolvable from Azure VM, we can check the DNS server is used for resolution in VM and set the same in the Logic App WEBSITE_DNS_SERVER setting and verify. Also, make sure that VNET integration is done with the appropriate VNET and subnet in Logic App. References: You may refer to the below blogs for deep dive into Standard Logic App runtime and deployment using DevOps. Azure Logic Apps Running Anywhere – Runtime Deep Dive (microsoft.com) Deploying an Azure Logic Apps Standard workflow through Azure DevOps Pipeline - Microsoft Tech CommunityDeploying Logic App Standard resource through DevOps pipeline
Automating the deployment of Logic Apps Standard through a CI/CD pipeline requires a different process from that used by Logic Apps Consumption. As Logic Apps Standard now encapsulates a group of workflows in a single unit of deployment (the Logic App Standard App), to fully automate the deployment process the following artefacts are required: Infrastructure components Logic Apps Standard App (including dependencies like App Service Plan and Storage accounts) Managed Connectors (also known as Azure Connectors) Code components Workflows Connection settings (connections.json) Parameter settings (parameters.json) Application settings configuration
Trigger workflows in Standard logic apps with Easy Auth
#Edits June 18, 2024 The Easy Auth can be configured from UX on a Standard Logic App in the "Authentication" blade under the Settings group. Apps that already have Auth Settings V2 configured will also display the details in this blade. Sample screenshot: #EndEdits For single-tenant Azure Logic Apps, we're adding the capability in Standard logic apps to set up Azure Active Directory (Azure AD) authorization policies. When a Standard logic app workflow starts with the Request trigger, which handles inbound HTTP calls, the logic app expects each received inbound request to present access tokens that include Azure AD policies. This authentication also permits requests for the location header from an asynchronous workflow. Similar to a Consumption logic app, you can specify the claim types and values that the logic app expects in the access token presented by each inbound request. Sometimes called "Easy Auth", this capability is an Azure Functions provision for authenticating access with a managed identity and is available through Azure App Service's built-in authentication and authorization capabilities. Easy Auth makes authenticating workflow invocations possible through triggers. Rather than use Shared Access Signature (SAS) tokens, you can use Easy Auth as a more secure authentication method that doesn't require access token regeneration. Basically, Easy Auth provides all the advantages available when you use a managed identity for authentication. For more information, review Authentication and authorization in Azure App Service and Azure Functions. Meanwhile, to set up authorization policies, you can call the Auth Settings V2 by using an HTTP client such as Postman. For more information about the Swagger description, review Auth Settings V2 - WebApps REST API. This article shows how to enable and use Easy Auth this way for authenticating calls sent to the Request trigger in a Standard logic app workflow. Enable Easy Auth on the Request trigger This section provides more information about calling the Auth Settings V2 API. To call the API, use the following HTTP request: PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2?api-version=2021-02-01 When you call the Auth Settings V2 API, replace all the property placeholder values, such as {subscriptionId}, with the actual values you want to use. However, in the request body, keep the following properties unchanged: "globalValidation": { "requireAuthentication": true, "unauthenticatedClientAction": "AllowAnonymous" } Note- EasyAuth is managed by AppService, and for an incoming request, it is a hop that that comes before LA Runtime. When EasyAuth is enabled for a Logicapp standard, all incoming requests are validated against the policies in your V2 Auth settings. If you have “unauthenticatedClientAction”: “Return401” and when the request fails with EasyAuth, those requests are not routed to LA runtime and will fail with 401 from AppService. Therefore, you will also observe broken portal experience with Return401. When you set it to “AllowAnonymous”, all calls (failed and successful) will be routed to the LA runtime. The LA runtime will know if the request failed with EasyAuth or was successful and will process the request accordingly. For example, to get run histories, we authenticate it on SAS specific to that run generated based on the Logic Apps access keys. LA runtime will know that this request failed with EasyAuth but it will be processed successfully as it has valid SAS. The underlying AppService platform will have no knowledge of validating other auth like SAS. The following list has more information about the specific properties that you use: - identityProviders.azureActiveDirectory.openIdIssuer: The token issuer for your Azure AD - identityProviders.azureActiveDirectory.clientId: The ID for your AAD App Registration. This will be augmented as an allowed audience. - identityProviders.azureActiveDirectory.validation.allowedAudiences: An array with the allowed audience values for the token - identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedPrincipals.identities: An array with the object IDs for the Azure AD identities, such as user/group The following example, which is attached at the end of this article, shows a sample payload to include as the PUT request body: { "id": "/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppName}/config/authsettingsV2", "name": "authsettingsV2", "type": "Microsoft.Web/sites/config", "location": "{locationOfLogicApp}", "tags": {}, "properties": { "platform": { "enabled": true, "runtimeVersion": "~1" }, "globalValidation": { "requireAuthentication": true, "unauthenticatedClientAction": "AllowAnonymous" }, "identityProviders": { "azureActiveDirectory": { "enabled": true, "registration": { "openIdIssuer": "{issuerId}", "clientId": "{clientId}" }, "login": { "disableWWWAuthenticate": false }, "validation": { "jwtClaimChecks": {}, "allowedAudiences": [ {audience1}, "{audience2}" ], "defaultAuthorizationPolicy": { "allowedPrincipals": { "identities": [ "{ObjectId of AAD app1}", "{ObjectId of AAD app2}" ] } } } }, "facebook": { "enabled": false, "registration": {}, "login": {} }, "gitHub": { "enabled": false, "registration": {}, "login": {} }, "google": { "enabled": false, "registration": {}, "login": {}, "validation": {} }, "twitter": { "enabled": false, "registration": {} }, "legacyMicrosoftAccount": { "enabled": false, "registration": {}, "login": {}, "validation": {} }, "apple": { "enabled": false, "registration": {}, "login": {} } }, "login": { "routes": {}, "tokenStore": { "enabled": false, "tokenRefreshExtensionHours": 72.0, "fileSystem": {}, "azureBlobStorage": {} }, "preserveUrlFragmentsForLogins": false, "cookieExpiration": { "convention": "FixedTime", "timeToExpiration": "08:00:00" }, "nonce": { "validateNonce": true, "nonceExpirationInterval": "00:05:00" } }, "httpSettings": { "requireHttps": true, "routes": { "apiPrefix": "/.auth" }, "forwardProxy": { "convention": "NoProxy" } } } } Call the Request trigger with Azure AD OAuth To call the Request trigger in your workflow using Azure AD OAuth, send a request to the callback or invoke URL by passing the Authorization header, but not the SAS tokens, in the query parameter using the following syntax: POST https://{logicAppName}.azurewebsites.net:443/api/{workflowName}/triggers/manual/invoke?api-version=2020-05-01-preview For example, in your HTTP client, which is Postman here, make the following call: Troubleshoot errors If the following errors happen, try the suggested resolutions: The request should have a valid Authorization header with "Bearer" scheme and the "WEBSITE_AUTH_ENABLED" appsetting set to true on the logicapp. This error means that your authentication token failed authorization. You can ignore the part about the "WEBSITE_AUTH_ENABLED appsetting" because you don't need to update this value on your logic app and is going to be fixed. Make sure that you've entered the necessary property values as specified in the Easy Auth setup section. The request has both SAS authentication scheme and Bearer authorization scheme. Only one scheme should be used. You can't use both SAS and Bearer authorization scheme tokens at the same time. You can use only one token because both tokens are valid and cause confusion when calling the request trigger.
Azure Logic Apps - Authenticate with managed identity for Azure AD OAuth-based connectors
Azure Logic Apps currently supports managed identities for specific built-in triggers and actions. This blog post announces preview support for using your logic app's managed identity to authenticate to Azure AD OAuth-based managed connector triggers and actions.Azure Logic Apps Running Anywhere: Built-in connector extensibility
A key capability in the redesigned Logic Apps runtime introduces the extensibility to add built-in connectors. These built-in connectors are hosted in the same process as the Logic App runtime and it provides higher throughput, low latency, and local connectivity.
