Skip to content
/

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

The problem

When we want to integrate an application with Azure AD we need to register an app.
In my case I want to let a user access an Azure SQL Database using delegation. So, the database connection will be created impersonating the user account, not a generic service account.

To grant delegation permissions to an API we go to the Required permissions section of the Azure AD app:
Required permissions menu item

When we’ve created a new app there is not much showing yet, other than the default Azure AD delegated permission to sign in as the user:
Required permissions pane with default entry

We click on the Add button and choose the Select an API option:

Select an API menu item

Here we get a list of APIs to choose from. But our Azure SQL Database is not listed.
There is a search function, but entering SQL, like my colleague did, didn’t list any results.

This is where I started to search online if other people encountered the same problem. One of the few related posts is by Michael Collier: .
In his post he mentions not having the API listed:

Before you can continue, you need to have followed the prerequisites steps stated at the top of this post. You especially need to be sure you have created an Azure AD contained database user. If you fail to do that, you will not see “Azure SQL Database” in the list (as specified below).

But following all his steps didn’t make the API appear.

After wasting more time not finding any other related posts, adjusting multiple settings, and recreating Azure AD apps, I suddenly found a lead that pointed me in the right direction

The solution

One of the apps I created was named AzureSqlAppTest. Because the list of registered apps is quite long I wanted to use the search function and I entered the word SQL.
To my surprise no results. Entering AzureSQL did show my app.

The search function in the Azure Portal is acting only as a Begins With filter!

Desperately, I tried this trick on the API list as well. Maybe the API search function doesn’t show SQL related APIs because the name doesn’t start with SQL.

Instead of SQL I entered Azure in the search box, and to my amazement: a whole new list of never-before-seen APIs showed up, including our Azure SQL Database:
Select an API pane listing many APIs that where hidden

There are many more APIs available in the Azure Portal, there is just no indication in the UI!

After re-reading Michael Colliers blog post, I found he did mention this at the end of one of the steps:

3. Add a new required permission and select Azure SQL Database as the API. You’ll want to search for “azure” to get “Azure SQL Database” to appear in the list.

Now we can configure our app, and everything will work as expected.

The conclusion

Just because the Azure Portal UI doesn’t give any hint there are many more APIs hidden behind the search function, I wasted a lot of good time.
I hope this post will prevent you from wasting yours, and I hope the Portal UI will improve.

Filed under Azure
Last update:
/

Azure Key Vault is a great resource to store your secrets like passwords, connection strings, certificates, etc. and access them programmatically. A great feature is to add or update your secrets during deployment so you don’t have to manage your secrets manually. In this post, I’ll explain how you can add secrets to an Azure […]

Azure Key Vault is a great resource to store your secrets like passwords, connection strings, certificates, etc. and access them programmatically. A great feature is to add or update your secrets during deployment so you don’t have to manage your secrets manually.

In this post, I’ll explain how you can add secrets to an Azure Key Vault using ARM templates.

At the end of the post you will find the link to the source code.

Creating the Key Vault

First, we create the Key Vault to store all our secrets.
You can add an access policy so you’re able to see and manage the secrets using, for example, the Azure Portal.

To create a Key Vault, we add the following resource to the ARM template:

{
  "type": "Microsoft.KeyVault/vaults",
  "name": "LoremVault",
  "apiVersion": "2015-06-01",
  "location": "[resourceGroup().location]",
  "properties": {
    "sku": {
      "family": "A",
      "name": "Standard"
    },
    "tenantId": "[subscription().tenantId]",
    "accessPolicies": [
      {
        "tenantId": "[subscription().tenantId]",
        "objectId": "CHANGETO-YOUR-USER-GUID-000000000000",
        "permissions": {
          "keys": [ "All" ],
          "secrets": [ "All" ]
        }
      }
    ]
  }
}

Adding a plain text Secret

With the Key Vault in place, we can start adding secrets to it.

We add a resource to the ARM template to describe the secret.
The name must be prefixed with the name of the Key Vault. We also declare that the resource depends on the Key Vault resource. This ensures the Resource Manager doesn’t try to store the secret before the Key Vault is created.

A secret consists of two properties:

  • contentType contains the of the secret
  • value contains the value of the secret
{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/SomeSecret",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "text/plain",
    "value": "ThisIpsemIsSecret"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]"
  ]
}

Adding a certificate as a Secret

This is almost the same a storing a plain text value.
Change the contentType to application/x-pkcs12 and add the certificate as encoded string to the value:

{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/SomeCertificate",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "application/x-pkcs12",
    "value": "MIIV0QIBAzCC...yada...yada...RIJcq3QACAggA"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]"
  ]
}

Besides storing hardcoded values it’s also possible to use parameters, variables, or even the output of other resources as source for the value of your secrets.

Adding a connection string to a Storage Account

Let’s make a Secret resource containing the connection string of an Azure Storage Account.

First, we add a Storage Account resource to the ARM template:

{
  "type": "Microsoft.Storage/storageAccounts",
  "kind": "Storage",
  "name": "loremipsumstore",
  "apiVersion": "2016-01-01",
  "sku": {
    "name": "Standard_LRS"
  },
  "location": "[resourceGroup().location]"
}

Now we add a Secret resource that is depending on the Storage Account and the Key Vault defined earlier.
The value of the secret is set with a connection string containing the first access key of the Storage Account:

{
  "type": "Microsoft.KeyVault/vaults/secrets",
  "name": "LoremVault/ConnectionString",
  "apiVersion": "2015-06-01",
  "properties": {
    "contentType": "text/plain",
    "value": "[concat('DefaultEndpointsProtocol=https;AccountName=loremipsumstore;',
              AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', 
              'loremipsumstore'), providers('Microsoft.Storage', 'storageAccounts')
              .apiVersions[0]).keys[0].value, ';')]"
  },
  "dependsOn": [
    "[resourceId('Microsoft.KeyVault/vaults', 'LoremVault')]",
    "[resourceId('Microsoft.Storage/storageAccounts', 'loremipsumstore')]"
  ]
}

Thanks to Maarten van Sambeek for sharing this code with me.

Now you have stored your connection string securely without it ever surfacing outside of your deployment. If you use access policies so your application reads the connection string directly from Key Vault, you don't have to store your connection string anywhere where it’s readable like in a web.config file.

Source code

I’ve create a GitHub Gist with the a full working Key Vault deployment template sample for reference.

Filed under Azure
Last update:
/

When I start on a project that uses Azure resources, one of the first things I do is build the infrastructure and automate the deployment using VSTS or TFS.
In this post I‘ll explain how you can extend Azure Web Apps with Virtual Applications and Virtual Directories using ARM templates.

When I start on a project that uses Azure resources, one of the first things I do is build the infrastructure and automate the deployment using VSTS or TFS. The definition of the infrastructure is defined using ARM templates.
When you search online you will find plenty of examples on how to create and use ARM templates. But when you move beyond the basics you’ll find out the documentation is lacking.

In this post, I’ll explain how you can extend Azure Web Apps with Virtual Applications and Virtual Directories using ARM templates.

I won’t be covering on reasons why you would want to use Virtual Applications or Directories. If you’re interested in more background on these, you can read .

At the end of the post you will find the link to the source code.

The Web App definition

We start with a basic site template, for brevity I skipped the app service definition.
The resources property is an empty collection by default.

{
  "type": "Microsoft.Web/sites",
  "kind": "app",
  "name": "LoremIpsumWebApp",
  "apiVersion": "2015-08-01",
  "location": "[resourceGroup().location]",
  "resources": [],
  "dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', 'LoremIpsumAppService')]"
  ]
}

Adding the Configuration resource

Configuration of the Web App properties is done with a resource with the type of Microsoft.Web/sites/config.

The name of the resource starts with the name of the parent Web App extended with /web.

In the property properties, you can configure several configuration properties like Virtual Applications, enabling Always On or disabling PHP.

A Web App always contains a root application.

{
  "type": "Microsoft.Web/sites/config",
  "name": "LoremIpsumWebApp/web",
  "apiVersion": "2015-08-01",
  "dependsOn": [
    "[resourceId('Microsoft.Web/sites', 'LoremIpsumWebApp')]"
  ],
  "properties": {
    "phpVersion": "",
    "alwaysOn": "true",
    "virtualApplications": [
      {
        "virtualPath": "/",
        "physicalPath": "site\\wwwroot",
        "virtualDirectories": null
      }
    ]
  }
}

We add the new config resource as a child resource to the Web App:

{
  "type": "Microsoft.Web/sites",
  ...
  "resources": [
    {
      "type": "Microsoft.Web/sites/config",
      ...
    }
  ],
  ...
}

Other properties trimmed for brevity.

Adding Virtual Applications

We can add a Virtual Application by adding it to the virtualApplications array.
There are 2 required properties:

  • The virtualPath is the relative path to the root URL of the website.
  • The physicalPath is the (relative) path on disk where the files for this application are stored.
{
  "virtualPath": "/DolorSitAmet",
  "physicalPath": "site\\dolor-sit-amet",
  "virtualDirectories": null
}

Adding Virtual Directories

Virtual Directories are always a part of a Virtual Application.

A Virtual Directory has the same two required properties that are needed for a Virtual Application: virtualPath and physicalPath.

{
  "virtualPath": "/Images",
  "physicalPath": "site\\path-to\\images"
}

This object is added to the Virtual Application:

{
  "virtualPath": "/DolorSitAmet",
  "physicalPath": "site\\dolor-sit-amet",
  "virtualDirectories": [
    {
      "virtualPath": "/Images",
      "physicalPath": "site\\path-to\\images"
    }
  ]
}

Now you can deploy the ARM template to your Azure Resource Group and then configure a Web Deploy to your brand new Virtual Application!

Source code

I’ve create a GitHub Gist with the a full working deployment template sample for reference.

Filed under Azure
Last update: