Monday, December 1, 2014

Azure WebSites and Auth0 integration

A couple of weeks ago, I met with one of my long time friends, @tjanczuk.  Tomek (that is how people call him) is currently working at Auth0.  He was very excited to share with me about his new adventure with this company especially the problem space it is trying to solve.

Auth0 goal is to take care of the hard security aspect for your site and let you focus on your more important business logic.  One crucial necessity for online services is an ability to identify (or authenticate) their users.  If you are a well established company, you can afford to spend money and build one.  However, for start up or small business owners, it may not be cost efficient to do so.  It is even risky if it is not done in a secured manner.

I view Auth0 as a SaaS whose value proposition is to provide a one-stop identity service for your site.  Not only does it make easy (and safe) to secure your sites, it also provides a wide range of integration with popular identity providers such as (Azure Active Directory, Live/MSA accounts, Facebook, Google and much more).  This allows lots of flexibility for end users to sign in to the site.

Since I am one of Azure Websites developers, I took it as an exercise to demonstrate how simple it is to integrate Auth0 to sites hosted on Azure Websites.   I pick 2 simple scenarios below.   Note: you will need an Azure subscription in order to try them.

Scenario 1 Quick Start for Auth0 and Azure Websites

This is a quick start.  It demonstrates how to create a new Azure Websites with Auth0 enabled in one shot.  Simply follow the readme section repository.

To summarize, all you have to do is to create a new (or use an existing) Auth0 application.   Then simply click the Deploy to Azure button.   This will create and deploy the repository to Azure Websites.  Simply browser to the websites to see how Auth0 works.   All source codes are available as part of the repository.


Scenario 2 Add Auth0 to an existing Azure Websites

Let say you already have a website hosted on Azure Websites.   Don't worry if you don't have one, go to Azure Portal and simply create one.  For simplicity, let assume your website's name is foo and its url is   Browse to your site and you should get a standard landing page for Azure Websites.

To enable Auth0 is as simple as to enable the Auth0 site extension for your site.   Here is how.

  • Browse to  This is Site Control Manager (SCM) for your site.  In short, the SCM site (or Kudu service) allows you to manage and diagnose the issue your site.   More info can be found here.

  • One of the powerful feature is Site Extensions.  This enables communities to share and contribute the site extension that would enhance the functionalities of the site.  Select Site Extensions tab.

  • Select Gallery tab.

  • You will see many available Site Extensions.  Locate the Auth0 Extension and click install.

  • After install (or uninstall) Site Extension, you will need to restart the site.   To restart, go to Azure Portal, select your site.  You can find the restart button on the command bar at the bottom.  
  • Browse to your site ( and follow the instructions.  You should be familiar with this by now.

  • Refresh your site (  You should see now that the site is integrated with Auth0!

All source codes for Site Extension are available at  Let me know @suwat_ch for any issue.

Monday, July 22, 2013

Using Azure Websites Diagnostic Console


This feature allows you to do something along the line of remote command shell on your Azure Websites file system.  For instance, you can perform simple shell commands like "cd", "dir", "mkdir" etc.   Internally, these commands are executed remotely on Azure WebSites and against its file system.   If you were to "del" pr "rmdir" a file or folder, it will behave the same way as you were to FTP and delete the file manually.

To access this feature, follow the below steps.

1.  Connect to the SCM endpoint of your Websites.

This feature is exposed via the SCM (Source Control Manager) endpoint as part of your WebSites.   To connect to SCM endpoint, simply add "scm" between your site name and subdomain.   For instance, if your site url is "", the scm endpoint is "".  You can browse to "".  

This SCM endpoint requires username and password.   This information is available in your site publishing profile which you can download from Azure Portal Websites QUICKSTART or DASHBOARD (the username is usually your site name prefixed with "$" and the password is a long cryptic one).    By the way, if you happen to setup git publishing for your site, you can also find this credential and URL on your site CONFIGURE tab under "deployments" sections.

Browse to SCM endpoint should land you on this page.

2. Launch the Diagnostic Console

Click the "Launch" shown in picture above should open the console.

Now, you can experiment by typing "dir" or "cd" commands.  The Azure Website file structure is described here.  Enjoy!

Wednesday, July 17, 2013

Enable Git for existing Azure WebSites


Azure Git deployment provides source control and versioning deployment.  The benefit is the ability to get the history of deployments and to rollback to any point in history.

If you have existing WebSites which is deployed by other means such as WebDeploy (Gallery) or FTP and want to enable Git publishing over those deployed files.   You can achieve it by the following.

Step 1 Enable Git Publishing on your site.

Logon to Azure Portal, select your site and navigate to the Dashboard.

Click "Setup up deployment from source control" and double click "Local Git repository"

Step 2 Download (Clone) deployed files to your local machine

Your site is now Git enabled.  You can now download (clone) the content of your site to your local machine.  This is done by simply using git clone command.  The Git URL for your site can be found on the Deployments page.

That's it.  After the clone is done, you can modify local files, git commit and deploy (git push) to your site.

Saturday, July 6, 2013

Deploy to Windows Azure using git with private submodules


Windows Azure supports continuous deployment from GitHubBitbucket and CodePlex.  This includes both public and private repositories.   For private repository, Windows Azure generates an SSH key pair.  The public SSH part is added to the repository's deployment key while the private one is used to fetch the repository content during deployment.  If the repository contains submodules, their contents will also be fetched automatically.

It becomes interesting when submodules happen to be private repositories.   Since Windows Azure, by default, uses the same SSH private key to fetch the main repository as well as its submodules, one can workaround by manually propagating the SSH deployment key across all related submodules.  Note that you have to make sure all submodules are fetched using SSH (not https) by looking at .gitmodules file (see url property).  This works well with Bitbucket but fails in GitHub.   The reason is GitHub uses SSH key as an identifier; hence, it can only be defined once for either a user key or repository deployment key across GitHub site.

Below describes a few workarounds for the GitHub issue.

Dedicated user with pull permission

This is the simplest workaround by introducing a new dedicated user with pull permission to all related private repositories (main and submodules) required for deploying to Windows Azure and set an appropriate SSH key pair to this user and Windows Azure.  There are two ways to achieve this depending on whether your main repository is public or private.

If the main repository is private, the private SSH key is already set to Windows Azure and you will only need to deal with public key part.  Simply copy the deployment key (d:\home\.ssh\ from your webapp (using FTP or Kudu Console) and paste to this user as user SSH key.  Because GitHub only allows one unique key, you may have to delete the deployment key from repo before add as a user key.

If the main repository is public, Windows Azure will not generate nor set any SSH key pair.   In this case, you will have to generate the key pair manually (ssh-keygen).  The public part ( should be set as user key of the dedicated user above.  Upload the private key (id_rsa) part to Windows Azure (you may follow Giving the private key to the Kudu service instruction).

This is simplest and recommended way.

Use different SSH keys for each repositories

This solution is to take advantage of SSH alias support in SSH configuration.  This allows us to speficy different private key files (id_rsa) to be used to access different repositories.

Let's assume, we are dealing with 2 private submodules (say repo1 and repo2).  First, generate two set of key pairs (one for each repositories) and add the public part as deployment key for appropriate repositories.

Configure the ssh configuration file (~/.ssh/config) to use different private key files for different repositories as follow.

Host github-repo1
    User git
    IdentityFile ~/.ssh/id_isa.repo1
    StrictHostKeyChecking no

Host github-repo2
    User git
    IdentityFile ~/.ssh/id_isa.repo1
    StrictHostKeyChecking no

You can test if it is properly configured by doing a git clone/pull from each repositories.

$ git clone git@github-repo1:account/repo1.git
$ git clone git@github-repo2:account/repo2.git

Use FTP to upload ~/.ssh/config, ~/.ssh/id_rsa.repo1 and ~/.ssh/id_rsa.repo2 to Windows Azure's /site/.ssh folder.    Modify and commit the .gitmodules file along with you rmain repository.

[submodule "repo1"]
  path = repo1path
  url = git@github-repo1:account/repo1.git

[submodule "repo2"]
  path = repo2path
  url = git@github-repo1:account/repo2.git

Windows Azure should be able to fetch the main and its submodules successfully.   By the way, this solution only works well if you are the only one using these repositories and your have propagated the ssh's configuration as well as id_rsa key files to all your git client machines.

Hope it helps.