Windows Server 2012 R2 Web Application Proxy and ADFS 3.0 Azure Lab

The following diagrams are based on a lab I built on Microsoft Azure IaaS leveraging Web Application Proxy and ADFS 3.0. to demonstrate single sign-on with claims based applications.

As I come from an application development and architecture background, I learned a great deal with Azure IaaS and system administration with respect to Azure Virtual Networks, Virtual Machines, IP addressing, Azure PowerShell and the Azure management portal, domain controllers, DNS, subnets, certificates and other relevant Windows Server Roles and Features. At the present time of May 2016, I thought I share my notes to help others who may find this helpful in the manner that it is built. Note that I have built this lab in March of 2015 given the Azure’s feature and capabilities at that time.

Lab Architectural Overview

Hosting Infrastructure

Microsoft Azure Infrastructure-as-a-Service

Virtual Network

One Virtual Network with three subnets
Subnet-DC for the domain controller and ADFS server
Subnet-Web for web applications and other applications such as SharePoint Server.
Subnet-DMZ for the Web Application Proxy

Network Security Groups

I didn’t implement any NSG yet, but for proper network security you would have NSG around each subnet to allow/deny traffic based on a set of Access Control List rules.

Windows Domain

All servers except for the DMZ are on the same rk.com domain, except for the Web Application Proxy server. For trivial reasons of it being in the DMZ and as a proxy server to the internet.

Public domain name

I purchased rowo.ca domain name to be used as part of public urls to internal applications.

Certificates

There was a great deal of certificate dependencies between WAP and ADFS and Relying Party (web apps) and token signing. This was a challenging learning point for me and to set things up appropriately and troubleshooting. The detailed topics involved public/private key, export/import certificates, authority chain, thumbprint, certificate subject name, SSL, server authentication, expiry, revocation, browser certificate errors, etc.

Azure Virtual Network configuration involving address spaces and subnets

I setup ADFS and added my simple .NET claims aware web application as a relying party trust.

I conducted the following test:

Logging into the rkweb1 web server (i.e. internal to the network), I opened the browser
1.Enter the url: https://rkweb1.rk.com/ClaimApp
2.Redirected to ADFS and then authenticated
3.Redirect back to the ClaimApp with access.

Testing withing internal network:

I configured the Web Application Proxy to publish the following applications to the internet.

Internet-facing External URLs are start with https://rowo.ca/ and are mapped to backend URLs starting with https://rkweb1.rk.com for the following applications.

ClaimApp

.NET claims based application using Windows Identity Foundation.
WAP Pre-authentication is ADFS

HTMLApp

HTML web application with no authentication.
WAP Pre-authentication is Pass-through. No authentication.

TodoListService

REST API with windows authentication
WAP Pre-authentication is ADFS

Accessing ClaimApp from the internet:

Accessing a REST API via a .NET WPF desktop application from the internet. User will be prompted for credentials in a separate dialog per OAuth.

Accessing ClaimApp through iOS Sarafi browser with device registration. In AD there is a dev

In Active Directory, my iPhone mobile device has been registered for added authentication and conditional access rules to applications.

In conclusion, I loved the fact that Azure has become my IT sandbox to learn and build solutions such as this remote access solution. Also, the Web Application Proxy is one of many other options in the market to publish out internal on-premises applications using ADFS to support single sign-on.

Online References that helped me build this lab