Trigger workflows in Standard logic apps with Easy Auth

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

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.

  1. 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
  2. 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"
    }

    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 Azure AD tenant
    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:

arjunchiddarwar_0-1648157004315.png

 

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.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.