Azure: App Service Authorization with AAD B2C

No-Code App Service Authorization using AAD B2C

While seemingly simple, it was difficult to find a solid how-to on the topic of how to use the native Azure App Service (aka WebApp) Authorization functionality to fence-off an application from the general public with an Azure AD (AAD) B2C directory.  After some stumbles, I came across this blog by CGillum that proved it could be done, which gave me hope.  Since the article was older, it did not have more recent screenshots and instructions, so I needed to adapt it some to fit the current services.

Part 1 - Create an App Service

Locate or create an Azure App Service that will be connected to Azure B2C. Once it is created, obtain the App URL and save it somewhere. It will be required in the App Registration later.

Part 2 - Create an Azure AD B2C Directory

This tutorial will assume you have already established an Azure AD B2C Directory (B2C) that you wish to leverage, however if needed, please create a B2C first by following one of the tutorials on the Microsoft Docs website.

Part 3 - Register your Application in the B2C Directory

Step 1. Switch Directories to AD B2C

If not already in the same directory as your B2C, change directories in Azure by selecting the directory filter icon in the header

Step 2. Create a New Registration

Navigate to App Registrations screen and add a new registration. Be sure to choose Web Application if prompted.

Step 3. Specify the Correct Redirect URI

In the new registration, navigate to the Authentication screen and add new Redirect URI with the URL to your application. *IMPORTANT* Be sure to add the following to the end of that URL: `/.auth/login/aad/callback`. This is the built-in AAD callback for Azure App Services and is required in order to authenticate your app through AAD.

Step 4. Allow Implicit Grants

As this tutorial is working under the premise there is no logic in your app doing the authentication, be sure the "Access Tokens" and "ID Tokens" check boxes are marked on that same Authorizations page.

Step 5. Generate a Client Secret

To keep the application secure (and to ensure other parties can't use this directory for their applications), generate a client secret and save it for later.

Part 4 - Update the Web App Authorization

Step 1. Obtain the OpenID Configuration URL

In order to have the correct URL configured in the Web App Authorization section, we need the OpenID Configuration URL for the Sign-In/Sign-Up policy we will be using. This can be found in the B2C Resource under "User Flows(Policies)" by selecting the Sign up and Sign in policy you wish to use, and hitting the "Run user flow" button. Copy the URL from the top of the page as shown below (do NOT use the endpoint URL listed at the bottom of the page).

Step 2. Enable Authorization on App Service

Open the App Service you would like to protect using the AAD, and navigate to the Authentication/Authorization page.  From there, enable App Service Authentication, choose Log in with Azure Active Directory on the drop-down box and choose Advanced configuration on the AAD Authentication Provider.

Step 3. Enter AAD Login Details

Now all the items copied from prior steps can be placed in their respective places, as shown in the following screenshot. You must choose Advanced configuration as, presumably, you will be authenticating against an AAD that is NOT the same AAD you logged into the Azure Portal. 

Next Steps

Now that this B2C fence has been established, individuals must authenticate with the B2C directory before they can access your Azure App Service. This was a no-code approach, however the next steps would be to modify your App Service source code to make use of the authentication just completed. It could be as simple as leveraging the

System.Threading.Thread.CurrentPrincipal.Identity.Name

to access the currently logged in user, or if you would rather go further, use the B2C documentation and sample code to access more attributes surrounding the user.

GitHub: Working with Git Forks for Pull Requests

Keeping a Fork in Sync with the Original

While opensource projects are meant to allow contributors to create modifications and submit those modifications back upstream, the process for doing so isn't always clear.  In a rapidly changing source repo, making a fork and keeping that fork in sync with the upstream (original repo) just so that you can submit a pull request can be tricky if one doesn't know about a few tricks.  This article explains one of those tricks in keeping a copy of the upstream repo as the master branch locally on your PC while your new feature branches pointed at your forked repo.

Step 1 - Fork the Original Repo

Most open source projects do not allow you to create a branch in the master project, which requires contributors to fork the original repo so that you can make changes there first before submitting the change to the upstream repo in the form of a pull request. The first step is to of course fork the original repo.  In GitHub, this can be done by clicking on the Fork icon at the top of the open source project you are working with.

Step 2 - Clone the Original Repo to Your PC

Once the fork is created, its time to clone this or the upstream repo to your PC so that you can create a new branch and begin editing the source code.  The clone can be done from either the fork or the upstream repo.  Either will work as we rebase-ing the fork with the upstream on a regular basis.

git clone [your clone URL here]
# assuming the clone was the upstream do the following to rename it to upstream
git remote rename origin upstream

Step 3 - Point Master Branch to Upstream

Now that we renamed the origin to upstream, we need to ensure that the master branch we obtained still points at this upstream repo (and not our fork). this is done by:

git branch -avv # existing branches like master are linked to upstream/xxx

Step 4 - Add the Fork URL as a new Remote

Now we need to add back in a new origin pointing at our fork so that all of our new branches point back to the fork and not the upstream repo.

git remote add origin [your fork URL here]

Step 5 (Option a) - Checkout a new Feature Branch (For New Branch in Fork)

Now we have our two remote created, we simply checkout a new feature branch to begin our work.

git checkout -b [Your Feature Branch Name]

Step 5 (Option b) - Pull and Checkout Feature Branch (For Existing Branch in Fork)

If you already have a feature branch in the Fork, we'll need to pull it to our local machine before we begin our work.

git pull origin [Your Feature Branch Name]
git checkout [Your Feature Branch Name]

Step 6 - Rebase Master

Now before any commits are completed, you will need to synchronize the master with the upstream repo and rebase our fork to the latest changes in that parent repo. Since we aren't making changes directly on master anyway in our fork, we will be using the Rebase command, which ignores any changes in master on your PC and will replace it with what is checked out from the upstream repo.

# switch to the master branch
git checkout master
# pull recent updates from upstream
git pull upstream master
# switch back to your forked-based feature branch
git checkout [Your Feature Branch Name]
# rebase the fork's master branch with the upstream master
git rebase master
# push the rebased master back up to our fork living in our fork remote
git push origin master --force

Step 7 - Commit and Push Changes to Fork

Assuming the changes are complete and the above step was completed moments before this step, just commit the code changes you made and push them to the fork.

git push origin [Your Feature Branch Name]

Step 8 - Submit Pull Request

As you return to GitHub or whatever cloud-based git repo you are using, submit your pull request to the upstream owners for their review and inclusion in a future version of their code. It's good form to do this as quickly as possible in order to avoid any chances of significant code changes coming into play before the pull request is reviewed.

---

Update 5/29/19: Adding descriptive/instructional link to rebase step.

Update 6/20/19: Adding Option a and b for Step 5