Looking for some advice here. We try to do our ARM deployments in "complete mode" most of the time. But with API connectors such as onedriveforbusiness we noticed that oauth is invalidated and someone has to go into the portal to re authorize the api connector again.
Is there a workaround available that solves this issue? Or should I just seperate the logic apps into a seperate deployment that runs in Incremental mode?
You could configure to use the service principal credentials passed to the ARM template.
The ARM Template used here was:
{
"type": "microsoft.web/connections",
"apiVersion": "2016-06-01",
"name": "[variables('Principal Data Factory Connection Name')]",
"location": "[resourceGroup().location]",
"dependsOn": [],
"properties": {
"api": {
"id": "[concat(subscription().id, '/providers/Microsoft.Web/locations/', resourceGroup().location, '/managedApis/azuredatafactory')]"
},
"displayName": "Service Princiapl Data Factory Connection",
"parameterValues": {
"token:clientId": "[parameters('Service Principal App Id')]",
"token:clientSecret": "[parameters('Service Principal Secret')]",
"token:TenantId": "[parameters('Service Principal Tenant')]",
"token:resourceUri": "https://management.core.windows.net/",
"token:grantType": "client_credentials"
}
}
}
Credentials are passed in the configuration. There is no need to authorize / authenticate.
Related
I am using Azure Key Vault connector in the logic apps and for deploying the logic apps using ARM templates.
In the ARM templates I have added the Microsoft.Web/connections resource to include Key Vault API connection.
The API Connection gets successfully deployed, but when I open it on the portal to Authorize it I get an error :- "Failed to edit Api connection "keyvault"".
The resource template of the key vault looks like below :-
{
"type": "Microsoft.Web/connections",
"apiVersion": "2016-06-01",
"name": "[parameters('connections_keyvault_name')]",
"location": "[parameters('location')]",
"properties": {
"api": {
"id": "[concat('/subscriptions/',subscription().subscriptionId,'/providers/Microsoft.Web/locations/', parameters('location'), '/managedApis/', parameters('connections_keyvault_name'))]"
},
"displayName": "",
"customParameterValues": {}
}
}
The status of the API connection after deployment always shows "Error". However, I am using office365 API connection as well which works fine after deployment i.e. when I authorize it, it allows me to save it.
Can anyone please help me with this issue? This is blocking us to move this logic app to production.
Thanks,
Archana Kolte
You have to add the key vault name to connect to by setting the vaultName property under properties.paramaterValues.
Also, the end of the properties.api.id is the same for all Key Vault API Connections and should be /managedApis/keyvault.
Your ARM template would look something like this
{
"type": "Microsoft.Web/connections",
"apiVersion": "2016-06-01",
"name": "[parameters('connections_keyvault_name')]",
"location": "[parameters('location')]",
"properties": {
"api": {
"id": "[concat('/subscriptions/',subscription().subscriptionId,'/providers/Microsoft.Web/locations/', parameters('location'), '/managedApis/keyvault')]"
},
"displayName": "",
"parameterValues": {
"vaultName": "<name-of-your-key-vault>"
}
}
}
I have developed a Logic app and want to deploy it using parameter file.
When we use service bus connector into logic app we have service bus connection string so we can make it as a parameter for service bus connection string.
But while using salesforce connector it will ask for login into designer panel and generate a API connection for salesforce.
But while deployment i do not find any connection string or login credential url for salesforce connector.
I wonder how it will work for other resource groups while deployment?
Can your Logic App reference the existing salesforce connector? Salesforce connectors need to be authenticated; however, once authenticated I believe you can reference it in your ARM template by using something like the following in the Logic App:
"$connections": {
"value": {
"salesforce": {
"id": "[concat(subscription().id, '/providers/Microsoft.Web/locations/', 'CONNECTION REGION', '/managedApis/', 'salesforce')]",
"connectionId": "[resourceId('Microsoft.Web/connections', parameters('salesforce_Connection_Name'))]",
"connectionName": "[parameters('salesforce_Connection_Name')]"
}
You can deploy the connection in the same template with something like this:
{
"type": "MICROSOFT.WEB/CONNECTIONS",
"apiVersion": "2016-06-01",
"name": "[parameters('salesforce_Connection_Name')]",
"location": "centralus",
"properties": {
"api": {
"id": "[concat(subscription().id, '/providers/Microsoft.Web/locations/', 'INSERT REGION', '/managedApis/', 'salesforce')]"
},
"displayName": "[parameters('salesforce_Connection_DisplayName')]",
"nonSecretParameterValues": {
"token:LoginUri": "[parameters('salesforce_token:LoginUri')]",
"salesforceApiVersion": "[parameters('salesforce_salesforceApiVersion')]"
}
}
}
You'd have to pass in the LoginURI as a parameter which if you have multiple Salesforce and Azure environments would be a good thing to reuse the same template with different parameters.
I have an ARM template that creates an Azure Key Vault followed by an Azure Kubernetes service. The problem is that the Azure Kubernetes service needs a Service Principle's Client ID and Client Secret passed in the first time I create it. So I run the application.json without the kubernetes_servicePrincipalClientId and kubernetes_servicePrincipalClientSecret parameters in the production.parameters.json file:
application.json
{
"comments": "Kubernetes Service Principal Client ID",
"type": "Microsoft.KeyVault/vaults/secrets",
"name": "[concat(parameters('key_vault_name'), '/KubernetesServicePrincipalClientId')]",
"apiVersion": "2018-02-14",
"properties": {
"contentType": "text/plain",
"value": "[parameters('kubernetes_servicePrincipalClientId')]"
}
},
{
"comments": "Kubernetes Service Principal Client Secret",
"type": "Microsoft.KeyVault/vaults/secrets",
"name": "[concat(parameters('key_vault_name'), '/KubernetesServicePrincipalClientSecret')]",
"apiVersion": "2018-02-14",
"properties": {
"contentType": "text/plain",
"value": "[parameters('kubernetes_servicePrincipalClientSecret')]"
}
}
The second time I run the ARM template, I add the following lines to my production.parameters.json file, so that the Client ID and Client Secret are retrieved from Azure Key Vault where they were stored the first time I ran the ARM template.
production.parameters.json
"kubernetes_servicePrincipalClientId": {
"reference": {
"keyVault": {
"id": "/subscriptions/[Subscription Id]/resourcegroups/[Resource Group Name]/providers/Microsoft.KeyVault/vaults/[Vault Name]"
},
"secretName": "KubernetesServicePrincipalClientId"
}
},
"kubernetes_servicePrincipalClientSecret": {
"reference": {
"keyVault": {
"id": "/subscriptions/[Subscription Id]/resourcegroups/[Resource Group Name]/providers/Microsoft.KeyVault/vaults/[Vault Name]"
},
"secretName": "KubernetesServicePrincipalClientSecret"
}
}
Unfortunately it looks like you can't create a service principal in an ARM template. Is there a better way to configure all this in an automated way, so that regardless of whether or not I'm running the template the first time or second time, I don't have to perform any manual steps?
no, those apis are not exposed to arm, there is no way of managing a service principal with an ARM Template. you can however create a script that will provision the service principal and pass its details to the arm template, or you can use some sort of tool to handle all of this for you (pulumi\terraform\ansible)
I have a logic app that I am trying to automate through an ARM Template.
The logic app requires a connection to Office 365. Below I have the template for the connection generated from the automation pane of the Azure Portal.
When I run the script it fails - there is an authentication issue between the Azure subscription and the Office 365 subscription.
LinkedAuthorizationFailed
The client has permission to perform action 'Microsoft.Web/locations/managedApis/join/action' on scope ... however the current tenant 'curr-tenant-guid' is not authorized
to access linked subscription 'linked-sub-guid' ...
I wont be able to create this trust to automate the provisioning, but I would like to create the connection as placeholder so that the logic app can be deployed and I can go back to the portal to authorise the connection. Is this possible? Are there any other alternatives?
{
"comments": "Office 365 user for file monitoring",
"type": "Microsoft.Web/connections",
"name": "MyOffice365User",
"apiVersion": "2016-06-01",
"location": "northeurope",
"scale": null,
"properties": {
"displayName": "readuser#example.com",
"customParameterValues": {},
"api": {
"id": "[concat('/subscriptions/a6720ff8-f7cb-4bc8-a542-e7868767686/providers/Microsoft.Web/locations/northeurope/managedApis/', 'MyOffice365User')]"
}
},
"dependsOn": []
}
I found three post related to the same problem:
Deploying a logic app using ARM templates/powershell
Azure Logic Apps - ARM template to deploy filesystem API connection
How to set the connection string for a Service Bus Logic App action in an ARM template?
The problem is the same for all API Connection.
Connection parameters to access the specific service are stored on Azure and when you try to export the ARM Template there is nothing regarding these specific parameters (which make sens as Azure will not expose your secret, password...).
The trick is to query Azure Resource Management API to return the parameters needed for any connection in a Logic App.
Just follow the instructions on this article:
Deploying in the Logic Apps Preview Refresh
Use the below link to install logic app tool which can help to design workflow
https://marketplace.visualstudio.com/items?itemName=VinaySinghMSFT.AzureLogicAppsToolsforVisualStudio-18551
once done you can create office 365 connector and when you open ARM template you can see o365 component in the ARM template.
My template looks like :-
{
"type": "MICROSOFT.WEB/CONNECTIONS",
"apiVersion": "2016-06-01",
"name": "[parameters('office365_1_Connection_Name')]",
"location": "[parameters('location')]",
"properties": {
"api": {
"id": "[concat(subscription().id, '/providers/Microsoft.Web/locations/', parameters('location'), '/managedApis/', 'office365')]"
},
"displayName": "[parameters('office36`enter code here`5_1_Connection_DisplayName')]"
}
}
and inside workflow
"triggers": {
"When_a_new_event_is_created_(V2)": {
"type": "ApiConnection",
"inputs": {
"host": {
"connection": {
"name": "#parameters('$connections')['office365']['connectionId']"
}
},
"method": "get",
"path": "/datasets/calendars/v2/tables/#{encodeURIComponent(encodeURIComponent('AAMkNbPwESLK3F8s5n1Q3BwAhXXXXXXXXXXXXXXXXXXXXXXXXXXX'))}/onnewitems"
},
"recurrence": {
"frequency": "Minute",
"interval": 1
},
"splitOn": "#triggerBody()?['value']"
}
}
================================================================
And the parameters for workflow
"parameters": {
"$connections": {
"value": {
"office365": {
"id": "[concat(subscription().id, '/providers/Microsoft.Web/locations/', parameters('location'), '/managedApis/', 'office365')]",
"connectionId": "[resourceId('Microsoft.Web/connections', parameters('office365_1_Connection_Name'))]",
"connectionName": "[parameters('office365_1_Connection_Name')]"
}
================================================================
Logic app connectors are closed source and the 'Automation Script' option in the Azure portal strips the authentication portions of the properties node from connectors. This is what the portal hands you when you script out the ARM template for a logic app which talks to CRM.
{
"comments": "Generalized from resource: '/subscriptions/<guid>/resourceGroups/<resource group name>/providers/Microsoft.Web/connections/dynamicsCRMconnector'.",
"type": "Microsoft.Web/connections",
"name": "[parameters('connections_dynamicsCRMconnector_name')]",
"apiVersion": "2016-06-01",
"location": "eastus",
"scale": null,
"properties": {
"displayName": "CRMConnection",
"customParameterValues": {},
"api": {
"id": "/subscriptions/<guid>/providers/Microsoft.Web/locations/eastus/managedApis/dynamicscrmonline"
}
},
"dependsOn": []
}
The other connectors (SFTP, storage account, etc.) have the missing elements node documented here and there (nothing official from MS, but blog posts and sample code) but I can't find the information for the Dynamics connectors. As an example of what I would expect to see, here is how SFTP and storage accounts can be pre-configured with authentication values in ARM:
{
"type": "Microsoft.Web/connections",
"apiVersion": "2016-06-01",
"name": "[variables('sftp_conn_friendly_name')]",
"location": "[resourceGroup().location]",
"properties": {
"displayName": "SFTP connection",
"parameterValues": {
"hostName": "[variables('sftp_host')]",
"userName": "[variables('sftp_user')]",
"password": "[variables('sftp_pass')]",
"portNumber": "[variables('sftp_port')]",
"giveUpSecurityAndAcceptAnySshHostKey": true,
"disableUploadFilesResumeCapability": false
},
"api": {
"id": "[variables('sftp_conn_managed_id')]"
}
}
},
{
"type": "Microsoft.Web/connections",
"apiVersion": "2016-06-01",
"name": "[variables('storage_conn_friendly_name')]",
"location": "[resourceGroup().location]",
"properties": {
"displayName": "Blob connection",
"parameterValues": {
"accountName": "[variables('storage_account_name')]",
"accessKey": "[listKeys(variables('storage_account_name'),'2015-05-01-preview').key1]"
},
"api": {
"id": "[variables('storage_conn_managed_id')]"
}
}
}
While not a direct answer to your question, but a more general answer giving you idea how to act in such a situation. If its not documented anywhere your only hope is reversing it (and more often than not it works).
First of all, this connecter is a resource in Azure (like the ones you've written). You can use any of the available ways to get the resource properties (https://resource.azure.com, Get-AzureRmResource, REST API, various SDKs) and see what the values are like there.
Another way of going about this - creating this connector using the portal and capturing traffic with fiddler. That way you will see the exact REST call needed to créate such a connector and would be able to replicate it using ARM Template. You might not know that ARM Templates are basically proxies for REST calls. Each resource you are creating is being converted to a REST call and performed against the appropriate resource provider.