Category Archives: Azure


Authenticate against an Azure Mobile Service app with ADAL.js

In one of my current projects I was trying to access a Azure Mobile Service from within a HTML Angular app. “Great!” I thought, let’s use ADAL.js and let the magic happen! So I installed ADAL.js, configured it and…..nothing, ADAL.js injects the Bearer token but I got a “401 unauthorize” from the Azure Mobile Service. After some research on the web I was able to get Azure Mobile Service authentication to work with an ADAL.js acquired authorization token.

The Setup

As mentioned above there are 2 “apps”, an HTML Angular app and an Azure Mobile Service app with a .NET backend. Both apps uses Azure Active Directory as the authentication backend, the following image shows this setup.


Azure Mobile Service app

We will start with the Azure Mobile Service app. Microsoft provides a detailed explanation on how to configure the windows azure active directory authentication for azure mobile service in this article.

After configuring the Azure Active Directory application for the Azure Mobile Service you only need to add the following configuration to the web.config of your Azure Mobile Service:

This options allows us to call the azure mobile service from the specified host (e.g. localhost). This option is only necessary if you like to call an Azure deployed Mobile Service app.

HTML app

After Creating the Azure Mobile Service AAD application we create a new AAD app for the HTML app with the following settings:


Note: The APP-ID Url must not be a real URL, it’s more a unique identifier for your app. More Information about this here

After creating the Azure Active Directory app we can configure out HTML Angular app to use this AAD app with ADAL.js:

You can get the ClientID from the Azure Active Directory app:


The redirectUri should also match the reply url you’ve configured in your Active Directory app:


For more information about how to use ADAL.js with Angular take a look at Vittorio Bertoccis blog post.

Another important step is to configure “oauth2AllowImplicitFlow” option in the AAD app Manifest. You can download this manifest from the “Configure” page of the AAD application:


After downloading the manifest open it and set “oauth2AllowImplicitFlow” to “true”. This enables the OAuth client flow which is needed for client side (=javascript) authentication.

The last configuration we need to apply allows our HTML app to request access tokens for the Azure Mobile Service app. To do this we need to add the Azure Mobile Service app under “permissions to other applications” and delegate the “Access” permission:


Note: After clicking “Add application” you have to select “all Apps” to list all available apps.

Authenticate against Azure Mobile Service

Now that we have configured Azure AD for our HTML and Azure Mobile Service app we can extend the HTML app to authenticate against the Azure Mobile Service. To do this, we need to tell ADAL.js that we want to authenticate against this endpoint, so we need to add an endpoint configuration to out ADAL.js config:

The first part of the endpoint is the url of the endpoint, the second part is the APP-ID URI of the Azure Mobile Service AAD application. ADAL.js now injects into every call to the specified endpoint url a bearer token. Sadly Azure Mobile Service doesn’t use this token for authentication. Instead it uses its own token provided in a “X-ZUMO-AUTH” header. To get the token we can use the client-directed login operation . This allows us to get an Azure Mobile Service auth token for an already obtained AAD token. So we need to obtain an OAuth token for our Azure Mobile Service AAD app and present this token to Azure Mobile Service to get a valid Azure Mobile Service token. A little bit complicated but OK, let’s try this:


After this long post here are the key points:

  • Create a Azure Active Directory application for the Azure Mobile Service app and the HTML app
  • The HTML AAD app must have the set the “oauth2AllowImplicitFlow” option to “true” in the manifest
  • The HTML AAD app must have access to the Azure Mobile Service app (under “permissions to other applications)
  • The HTML App must have ADAL.js be configured with a endpoint for the Azure Mobile Service app
  • You have to use the client-directed login operation in your HTML app

If you find a more elegant solution for this problem or need further help, please let me know.


SharePoint – Providing operations on Azure?


A recent question attracted our interest:
Can we utilize Microsoft® Azure and extend our service portfolio to provide operations?

Before answering this question, let me introduce the problem.
As a successful solution provider for Microsoft® SharePoint and SharePoint based applications, we neglected operations. Mainly, because we cannot – could not – provide the necessary hardware and Service-Level-Agreements (SLA), and secondly, because we were never asked to provide such measures. Furthermore, cloud-based solutions were not available especially because Microsoft® explicitly did not support cloud-based SharePoint farms. Until now.

Today things are changing rapidly – and customers usually do not apply the brakes to their business. This is when we were asked if we could provide SharePoint as a hosted or managed service. And it’s exactly when we started to analyse the capabilities of Microsoft Azure as related to our customer’s needs:

Technical service scenarios

We examined four possible service scenarios:

  1. Hosted SharePoint
    Azure provides Infrastructure as a Service (IaaS), the service provider deploys and maintains Active Directory (AD) and SharePoint VMs and customers use “SharePoint as a Service”.
    Customers have no administrative rights on the VMs and have defined access rights to SharePoint.
  2. Managed
    Azure provides IaaS, we deploy and maintain AD and SharePoint VMs as stipulated by contract, customers maintain and use the system.
    Customers have defined administrative access rights to the SharePoint farm.
  3. Dedicated
    Azure provides IaaS, we set up AD and SharePoint VMs as stipulated by contract, customers maintains and use the system – or delegate maintenance the service provider. Further services are provided as agreed.
    Customers have full administrative rights.
  4. Testbed
    Azure provides IaaS, service provider sets up AD and SharePoint VMs, depending on customer’s testing requirements

Figure 1 illustrates the mentioned service scenarios, showing the level of responsibility and influence of the participating parties, with Microsoft always being responsible for Azure itself.

Responsibilities by service scenario on Azure

Figure 1 – Responsibilities by service scenario on Azure

Despite these scenarios three more use-cases should be considered:

  • Azure enables service providers to scale a SharePoint farm instantly, depending on current load and/or needs – without charging customers unnecessarily during calm phases
  • It is now reasonable to operate a second backup-farm for failover purpose
    e.g. a local disaster or outage can be rescued by a cloud-mirrored SharePoint
  • With full Hyper-V-compatibility provided by Azure, a customer can easily move his virtual machines over to Azure

Advantages and possibilities for customer’s business

In the past, both cases required a higher need of greatly expensive resources (hardware, software, housings, infrastructure, energy, maintenance, etc.). Today, with cloud-based IaaS, business can concentrate on its main priorities by turning capital expenditure into scalable running expenses. This results in effective productivity and flexibility.

Let’s focus on the opportunities for your business, divided into the service scenarios:

A hosted SharePoint farm/service offers the highest ROI for a customer’s business and let’s focus on a company’s core business. It is not mandatory to invest in hardware and care about operations. The service provider will deliver a worriless SharePoint experience. That’s why hosted SharePoint is a value for small business, too. But if customers are looking for a higher grade of flexibility…

Flexibility is more in focus on a managed SharePoint farm and offers the technical personnel larger freedom in supporting their company’s business workflows. Without any need of high investments, though.

Does an enterprise want or need a steady hand on the tiller? Then a dedicated SharePoint solution is the goal: The IT department keeps full control, with the necessary support and configuration, provided by us.

Even if a customer just needs a safe and isolated testbed for update evaluation, backup-and-restore-tests, or the like, Azure can serve as you well!

What all of these solutions have in common is to seamlessly connect to an enterprise on premise network via secured VPN. Furthermore the cloud-based farm can be synchronized with the on premise Active Directory and SharePoint farm.

Finally we conclude: Yes, Azure has the potential to extend our portfolio in a way that allows you to focus on your customer’s business, and thereby enabling us to provide you with the best chance in concentrating on your business!

Finally, one thing is for sure: If you are in need of a competent SharePoint solution provider – feel free to contact us!