Since the last few years, security has become a critical aspect of any IT solution. Data is a new wealth and data security is a primary requirement for all the customers developing IT solutions for their organizations. In this article, we will review the two types of Azure Webjobs, then see what Azure Webjobs Webhook URL is, and finally learn how to secure Webhook API with Azure AD.
Introduction
Before diving into the security aspect of Azure Webjobs, let's first try to understand what webjobs are.
If we want to define it in simple words, Azure Webjobs are Microsoft's PaaS solution to run background jobs. Basically, we can take them as direct replacement of Windows Service which we develop to run background jobs. They are part of Azure App Service and run in same instances as that of WebApps. We do not have to bear additional cost for the webjobs.
Similar to Windows Service, there are two types of Azure Webjobs:
- Continues - As the name suggests, they will run continuously until we stop them forcefully
- Triggered - They will not run until an external force starts them
Again, there are two types of Continuous Webjobs:
- Multi Instance - These webjobs will run the program on all the instances of app service plan of Azure App service in which webjobs are hosted. By default, all Continuous webjobs are Multi Instance webjobs.
- Single Instance - These webjobs will run the program only on one instance of app service plan of Azure App Service in which webjobs are hosted.
Similarly, Triggered webjobs are also of two types based on how they triggered:
- Scheduled Web jobs - These webjobs will start running the program at pre-defined time. But in case we require to trigger them beside their schedule time, we can do it by triggering manually by signing into Azure Portal or through Webhook URL
- Manually Triggered Web Jobs - which we have to trigger manually by signing into Azure Portal or through Webhook URL
To know more about the webjobs, you can read this MSDN article.
What is Azure Webjobs Webhook URL?
Azure Webjobs Webhook are nothing but the location of Azure Webjobs in Azure SCM site for that App service in which webjobs are hosted postfixed by the operation we want to perform on the Azure Web jobs.
For example, we have an Azure Webjob named "CodeProjectWebJob
" hosted in Azure App Service Named "CodeProjectAppService
" and we want to trigger this webjob through HTTP call, then webhook URL would be:
For a continuous Webjob
:
https://codeprojectappservice.scm.azurewebsites.net/api/continuouswebjobs/CodeProjectWebJob/run
Whereas for a triggered webjob
:
https://codeprojectappservice.scm.azurewebsites.net/api/triggeredwebjobs/CodeProjectWebJob/run
Here, run is command to trigger the webjob
s.
Apart from triggering webjob
s, we can do operations like delete webjob
s, get webjob
s history and many more. (for more information on this, visit here). This webhook
URL is secured with the default credentials where username is $appservicename
and password we can get from App service publish profile.
Secure Webhook API with Azure AD
We can also secure this webhook API with Azure AD authentication. To enable Azure AD authentication for webhook API, we need to follow the below steps:
- Register your App Service with Azure Active Directory
- Go to your app service and click on Authentication/Authorization in left panel.
- Enable App Service Authentication.
- Select "Log in with Azure Active Directory" in Action to take when request is not authenticated and click on Azure Active Directory box:
- In Management Mode, select Advanced.
- Provide Client Id and Issuer URL against which webhook should be authenticated and click OK and Save the settings.
- Provide Contributor Access:
- Again, go to your app service and click on Access Control from left panel.
- Go to Role Assignments.
- Select Contributor role from the Role dropdown.
- Add your Azure AD application.
Now Webhook API for your webjob is secured with Azure AD authentication.
While generating Azure AD access token to invoke webjob
, we need to make sure to provide https://management.core.windows.net as resource.
History
- 27th June, 2020 - Initial draft