In this post I will extend the previous example, by making the web application call a web api secured using Azure AD.

Now let me clarify this: the user will use OpenID Connect to authenticate to the web application, exactly as we saw in the previous post – in fact I’m reusing the same exact sample.

However, the web application at some point needs to call a web api which itself is protected using Azure AD and OAuth2. In this case the web application is the client and it will ask Azure AD for an access token to access the web api (using the OAuth2 Client Credential Flow); and this access token has nothing to do with the id token which was issued to the user to log in to the web application.

Here is a simplified conceptual illustration showing the main artifacts (not showing the protocol dance): Continue reading →

In the Azure Web Apps article, I created a web application and selected Azure AD authorization directly from VS during project creation. Behind the scenes, this registred the application in Azure AD and created the plumbing required to delegate authentication to Azure AD.

Now let’s examine a walkthrough to manually configure a web application to delegate authentication to Azure AD, using our knowledge of OpenID Connect.

First thing to do is to register our application in Azure AD and get our hands on the client id assigned to this application. As you know, in OAuth the client id is required during the protocol dance.

So from Azure old portal, register a new application (till the time I wrote this post, still Azure AD was only accessible from the old portal “manage.windowsazure.com”): Continue reading →

To make sense of this section, you need to already know the basic concept behind OAuth. So I won’t repeat what OAuth is and what scenarios it covers. Instead I will touch on some important topics to keep in mind (and commonly causes confusion to new identity developers) while working with an Authorization Server such as Azure AD.

As you probably know, OAuth spec/framework defines four flows: Continue reading →

So let’s have a quick word about OWIN/Katana.

OWIN is a standard, which defines an “interface between .NET web servers and web applications”. In other words its purpose is to decouple web servers and applications through an interface. Required cross-cutting functionality is then implemented through components called “middlewares” instead of being coded directly in the application. These middlewares fit together into a processing pipeline which processes incoming HTTP requests before they reach the application, and similarly process HTTP responses on their way back. This pipeline is therefore independent on any specific host, web server, or application framework. Continue reading →

Unlike Web Apps and API Apps which are basically containers where you deploy your web and API apps, Logic Apps allow us to build workflows by orchestrating a set of actions, such as calling APIs, consuming/update data, sending emails, and so on.

To perform actions, Logic Apps use connectors to connect to and consume resources that might or might not live inside Azure; for example API Apps, on premise APIs, Azure Blob Storage, SQL Azure, Azure SaaS such as SharePoint and Exchange Online and so on, in addition to other Logic Apps (hence creating composite orchestrations).

So why Logic Apps? Simply for anytime you want a workflow (i.e. business logic) to run in Azure that might perform any composite business function that you want. For example when a certain event occurs (for example a new order is placed) (called a trigger), you can have a Logic App that sends an email (an action), calls a log API (another action), checks a certain ERP store (action) and based on the result (a condition) updates a CRM SaaS (an action), and so on… Continue reading →

CORS stands for Cross-Origin Resource Sharing. It is a specification that specifies how a web server can allow its resources to be accessed by scripts running inside web pages on another domain.

So saying it another way: by default for security reasons, if you have a client side script inside a web page on domain1.com trying to access a resource (for example a web page or an API) on domain2.com, the browser will simply ignore the response. Read again: the API will send the response; it’s the browser that will ignore it.

Using CORS, the server and client use http headers to make accessing cross-origin resource possible. Where an origin is the combination of scheme (ex: http), host, and port of a URL. Continue reading →

Just as Web Apps allows us to get our web applications up and running easily without having to worry about all the traditional details, API Apps does the same for Web APIs.

API Apps present various new features, but two of the most important are API Definitions and CORS. In this post we’ll see API Definitions, in the next we’ll talk about CORS.

API Definitions

API definitions are very useful. See one of the few points that SOAP-based services is deemed successful even in the eyes of APIs advocates, is the presence of a powerful metadata standard in the form of WSDL. Web APIs lacked such support – at least in the form of a powerful standard although there are various options out these. Now of course, Web APIs have a standard interface so the need for metadata is already minimized, but still API consumers need to know about the structure of input and output data, and API Definitions help in this regard. Continue reading →

Deployment slots are a feature of Azure App Services, and can be used with Web Apps, API Apps, and Mobile Apps. Whatever your application type is (i.e. web application, web api, or a mobile app backend), Deployment Slots allow you to set up environments other than that of the production environment (like the one we setup implicitly in the previous article). This means you can for example setup a test environment and a staging environment; something which you traditionally have done in on premise development.

Go again to the Azure portal and create a staging deployment slot as follows. Here I create a slot with name staging, which will automatically create a web app under the name [originalwebappname]-staging; in my case myblogwebapp-staging: Continue reading →