Serverless Azure Architecture pt II, Adding User Authentication

This is Part II of articles in series discussing Azure Functions, a serverless way to execute custom logic on Azure.

Part I - Simple Forms Part II  - Adding Authentication Part III - Power Bi Dashboarding

Adding User Authentication

So we have our forms-solution up and running . Next we want to restrain the solution so that only my company's employees get access to the forms.
This happens on application level. In real every azure serverless function is being run on a server, of course, and behind the covers we are using Web Applications as the deployable unit to control and manage execution. This gives us some benefits since we already know that Web Apps can do a lot of nice things like talk to on-prem resources and implement proper security.

Benefits of declarative Auth

So this time we get to reap the benefits of the security subsystem that Web Apps have had for some time. It is really close to sweet spot when being used with scripting like we are doing today. The infrastructure serving the our function (and the invisible Web App) has a configuration item for turning security on and setting the most important settings like the underlying identity provider (Azure Ad, Facebook, Google, Amazon ,...).

So , after few clicks we have enabled the Authentication features of our Function and by using Azure Active Directory as the source we have effectively restricted the users into people that are in our AD, our employees that is.

Who's there

If You take a new inPrivate Browser session and try to reach Your function now You'll notice that You can't ... until You log in. After login things work just as they did before.
But very often our solution would like to know who the user is and use this information for something. Luckily that's easy.
Make new C# http Function and change the contents to something like this and try requesting it :

You'll notice that when You call the Url You will be getting Your own email back. Very simple. (did I say that I like simple ?).
You can use this information to add correct user info into database instead of relying on web form posts and such or by using some AD graph queries You can access more information about this logged-in user and use that info for various purposes.
Anywhere in Your app where You need to know the user name just refer request headers and dig the name up from there.

Summary

All this magic of course works since my three functions belong to the same underlying Web App and they share the same config ... another way around ... If You want to serve some functions to people outside Your own organization You would have to do that with an Service Function App that doesn't have the Auth enabled (by default it is off) and for Your internal audience You would enable the Auth just like we did.

So there You have it, adding proper enterprise-level auth on top of  Azure Functions is extremely easy and very useful tool in ones toolbelt.
Next time we will do some Power Bi Realtime Dashboarding and reporting with Azure Functions.