A while ago I wrote about Securing Azure Function with JWT tokens. Since that time a lot happened with Azure Functions so I revisited the topic and researched this again and wrote down the possibilities on how to protect your HTTP triggered Functions. Authorization Keys Authorization Keys are the simplest way to secure your functions. The key needs to be passed either via the query string (code) or with a HTTP header (x-functions-key) to the function and will be validated by Azure Function runtime/host.
Currently the most asked feature on UserVoice for Azure Function is integration of Azure KeyVault. Unfortunately this is not yet available out of the box.
In addition the solutions that are suggested are not very integrative as they do not support
AutoResolve properties or can not be used for connection strings on trigger or bindings.
Since Azure Function v2 still does not yet has support for dependency injection and this is still a hot topic, I decided to upgrade my soluton for this to Azure Function v2 and provide a nuget package!
Implementing IExtensionConfigProvider in a Function App is a common way to run code at startup of the Function App. It is also the place to register the components of your extension. In this post I will describe how Azure Functions finds and instantiates IExtensionConfigProvider implementations. There are several ways how an IExtensionConfigProvider implementation is found. Auto detection The auto detection works in Azure Functions V1 and V2. Auto detection of IExtensionConfigProvider implementation starts when the ScriptHost gets initialized.
While Azure Functions allows you to build very lightweight HTTP WebApis out of the box, the HTTP binding is very limited and sometimes we need access to the HTTP pipeline. In this post I show you how you can host a ASP.NET Core WebApi inside of a Azure Function. Prerequisites To get this working you need Azure Functions V2 Latest Azure Function Core Tools (install via npm, using npm i -g [email protected]) The ASP.
Today I stumbled about a Tweet that suggest to not use IOptions because it is a bad idea. IOption<T> is a bad idea and should not be used: https://t.co/FKlIa9iFlN — .NET Junkie (@dot_NET_Junkie) January 24, 2018 The tweet refers to a documentation page of SimpleInjector arguing why it is a bad idea to use IOptions. In this post I want to investigate the arguments and describe my opinions on those.
This is a short reminder post, mostly for my self, since I stumbled across this issue several times. If you are missing all user claims in the id_token, check if the property AlwaysIncludeUserClaimsInIdToken is set to true on the client.
Since the Azure Function runtime is now ported to .NET Core (currently in Beta) you are now able to develop and RUN Azure Function cross platform. The current core tools also come with docker support, which means you are able to run Azure Function inside a Docker container. To get the latest core tools, follow the steps in the announcement. Creating the docker container It is very easy to create your function with docker support.
In my daily job I need to create console applications quite often. The default Visual Studio 2017 console application template for .NET Core is very minimal and just contains the usual “Hello World”. But most of the time I need dependency injection, logging, want to have an async main, etc. I also like the structure of ASP.NET Core applications with its Startup class where you can configure your services. Therefor I created my own project template so I do not need to setup all this every time by myself.
I have completely rewritten this post. You can find the original post here. Out of the box it is only possible to secure your Azure Functions via Function Keys (API-Keys), which sometimes might not fit into your requirements. When using HttpTrigger we luckily have access to the current request and are therefor able to implement our own custom authentication/authorization methods. You could for example use JWT access tokens issued by an OpenID provider to control authentication/authorization.