In order to deploy from VSTS to an Azure App Service, you need to define an Azure Resource Manager service endpoint in VSTS. For this service endpoint you need:

  • a subscription ID
  • a tenant ID
  • a service principal client ID
  • a service principal

The first two are obvious, but for the service principal it's less straight-forward. Various articles suggest registering a new application in Azure AD, creating an API Access Key for the application, and setting the Contributor role for the automatically created user. The ID of the application and the (hidden) value of the key can then be used to fill in last two fields.

This works, but I have the feeling it's not the proper way to do this. One reason is that the app registration ask for a sign-on URL, which is not needed at all for VSTS. Second reason is that this registered app doesn't serve any purpose other than providing the service principal. The actual apps are Azure App Services.

Is this how it's intended, or is there a better way to acquire a service principal for the VSTS service endpoint?


Yes, this is the right way to do it. The service principal is essentially an app or an app identity, and you do use some of the features of it being an app such as granting access to API's and so on. The need for a URL is a hangover from the days when apps where just web apps and service principals didn't exists, and arguabley this could be made optional, but it hasn't yet, so you generally just make one up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.