In the last post we saw how you can configure Authentication for your Azure App using Google. You can configure Authentication using other providers too like Facebook, Twitter or Microsoft Azure Active Directory. And the good thing is that you can do this without modifying your deployed application.
In this post I want to show you a new Azure App service feature called Authorization which you can easily configure by just adding authorization.json file to your application root directory. Let’s take a look at this authorization.json file. For my simple example I have created as follows:
{ "routes": [ { "path_prefix": "/", "policies": { "unauthenticated_action": "AllowAnonymous" } }, { "path_prefix": "/Admin", "policies": { "unauthenticated_action": "RedirectToLoginPage" } } ] }
First you have a routes property which a collection of url authorization rules. There are different properties for each rule. In the above example, the first rule has path_prefix property set as ‘/’ and policy set as “unauthenticated_action” to “AllowAnoymous”. This means when I visit the home page allow anonymous access. But here is a caveat, this is only going to work if you have “Action to take when request is not authenticated” option set in the azure portal to “Allow Anonymous requests (no action)”. It was a bit confusing to me because I had this option set to “Login with Google” and it would not allow anonymous access with .json file. Check out my screenshot of my settings.
The next authorization rule in the above json says that when I navigate to /Admin page then redirect me to Login page and in my example it will be navigated to Google’s login page.
The basic schema of this .json file is as follows as shown in this msdn article.
{ "routes": [ { "http_methods": [ "GET", "POST", "PUT", ... ], "path_prefix": "/some/url/prefix", "policies": { "unauthenticated_action": "AllowAnonymous|RedirectToLoginPage|RejectWith401|RejectWith404" } }, ... ] }
You might be interested in knowing what does “http_methods” property does. It says that if a request is “GET” or “PUT” or “POST” then only this rule will be taken into effect for this url. If you want to restrict access to a particular page only if it is accessed via a “GET” request then you can just specifiy “GET”.
In path prefix you can have wildcards too which is very important if the url can have variable segments. For example, /product/1/edit then you can have path_prefix as /product/*/edit. For simple web applications this feature works great and I like how turn key solution this is.
Once again for this feature to work the authorization.json file has to be at the root of the application folder.