Demo : Azure Webapp Authentication Integration

Introduction

In the previous post I showed you how you can protect any web app without altering code. Now what if you want to go a bit further in terms of authorization? Today we’ll take a look into this capability.

 

Demo Outline

For today’s demo, I’ve created a small web app ;

Here we can see if the azure web app thinks we are logged in or not. It also presents us with the opportunity to login to an identity provider of our choice and afterwards logout. In addition, you are presented with all the header information as the web app receives from the underlying platform (being Azure Webapps).

 

The Mechanics

If you want to read up on more detail, do check this documentation page. It’s very good on the matter! In essence, the app service passes back user information via special headers ;

 

Working with user identities in your application

App Service passes some user information to your application by using special headers. External requests prohibit these headers and will only be present if set by App Service Authentication / Authorization. Some example headers include:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID
  • X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN
  • X-MS-TOKEN-FACEBOOK-EXPIRES-ON

Code that is written in any language or framework can get the information that it needs from these headers. For ASP.NET 4.6 apps, the ClaimsPrincipal is automatically set with the appropriate values.

 

So that explains why the demo is also showing you the headers. This way you can see with your own eyes what you can expect from the Azure Webapp.

 

Webapp Configuration

How did I configure the webapp in terms of authentication? I enabled the “App Service Authentication”, allowed anonymous requests and configured all identity providers.

This was pretty straightforward to do. If you are unfamiliar with the process of doing so. Do check the documentation, this is provides a very clear outline of what you need to do.

Anyhow, once you configured all of this, you’ll get some additional URLs added to your webapp ;

  • /.auth/me – user details
  • /.auth/logout – logout for all identity providers
  • /.auth/login/aad – login for azure active directory
  • /.auth/login/facebook – login for facebook
  • /.auth/login/google – login for google
  • /.auth/login/twitter – login for twitter
  • /.auth/login/microsoftaccount – login for microsoft accounts

Bare in mind that these URLs only become visible when you have configured the relative identity provider.

 

Webapp Code

As mentioned, all the code has been published on Github. Where the webapp is even directly to this repository ; 

Now how do I detect if a user is logged in or not?

I just check the header “HTTP_X_MS_CLIENT_PRINCIPAL_NAME”. The naming is kinda PHP specific, as the documentation refers to “X-MS-CLIENT-PRINCIPAL-NAME”.

 

Demo Screenshots

Feel free to give it a spin yourself! https://authdemo.kvaes.be/ And if you don’t trust my host, no offense taken! You can deploy it yourself too… 😉

Anyhow, here are some screenshots on what to expect ;

  • Login
  • Logout
  • Azure Active Directory
  • Facebook
  • Google
  • Twitter
  • Microsoft Account


Closing Thoughts

  • During this demo I was pondering about a possible overlap with Azure Active Directory B2C. Though in the end I see they both fit a specific purpose and probably will not intertwine.
  • I did not go and test what happens if we would work with claims.
  • In the past I used Auth0 a few times, like for the previous version of https://storage.kvaes.be/. For the use cases I had in the past, this integration would suffice.
  • Thinking out loud, I’m still curious how the header information would intertwine with single page (web)apps (typically JavaScript). With server-side processing you still have a lot of control over that. I can imagine that injecting headers would make these kind of apps require a different approach that does not directly match with this integration.

 

4 thoughts on “Demo : Azure Webapp Authentication Integration

  1. Great post. One question – I assume it’s not possible to re-style the default “You have successfully signed-in” page?

  2. Great article, the problem I have is, I’m doing this app service deployment thru an ARM Template and easyauth pages are not becoming available, do you know what may be happening ?

    1. Set one up via the portal. And then go to “Automation Script” on the Resource Group. Inside you’ll have the “inspiration” you’ll need for your template. It’ll be something like ;

      “siteAuthSettings”: {
      “enabled”: null,
      “unauthenticatedClientAction”: null,
      “tokenStoreEnabled”: null,
      “allowedExternalRedirectUrls”: null,
      “defaultProvider”: null,
      “clientId”: “9999999-9999-9999-9999-0e89a1f77523”,
      “clientSecret”: null,
      “issuer”: “https://sts.windows.net/c3bd02aa-9c55-4a65-8262-1492ddad94e0/”,
      “allowedAudiences”: null,
      “additionalLoginParams”: null,
      “isAadAutoProvisioned”: false,
      “googleClientId”: null,
      “googleClientSecret”: null,
      “googleOAuthScopes”: null,
      “facebookAppId”: null,
      “facebookAppSecret”: null,
      “facebookOAuthScopes”: null,
      “twitterConsumerKey”: null,
      “twitterConsumerSecret”: null,
      “microsoftAccountClientId”: null,
      “microsoftAccountClientSecret”: null,
      “microsoftAccountOAuthScopes”: null
      },

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.