Microsoft previews cloud-based Web apps proxy service in Azure

Microsoft has made available a preview of its upcoming cloud-based Web application proxy service based on Active Directory and Windows Server that seeks to better supporting remote access securely in BYOD programs and easing customer rollouts.

Called Azure AD Application Proxy, the service has a lot of potential upsides – all but eliminating corporate infrastructure changes in order to support remote access to Web apps behind the firewall, providing some DoS protection, eliminating need for VPN access to the apps, per-endpoint access control, support for multi-factor authentication and single sign-on to access multiple applications to name some.

+[Also on Network World: Construction firm previews Microsoft Azure Azure AD Application Proxy Service for authentication and ID management; ]+

It is based on features introduced in Windows Server 2012 R2, but not all of them will be available right away in the cloud-based Azure AD Application Proxy service. The service will reach parity with features available with on-premises services within a year, according to to Shai Kariv, group program manager for Microsoft’s Active Directory engineering team when he introduced the service at Microsoft’s TechEd North America 2014 last month.

Here’s how the application proxy service works if it’s deployed using corporate-owned Windows Server and Active Directory deployed on premises.

AD Application Proxy services lets remote machines connect securely to corporate Web without the need for VPNs and without the need to poke holes in corporate firewalls to let the traffic through.

It also all but eliminates the need to alter corporate internal infrastructure while giving IT departments a range of access policy controls and authentication options for remote devices, including non-Windows devices in BYOD programs.

These devices can be domain-joined or not, or can belong to a new in-between category called workplace-joined, which can be thought of as a lightweight domain-joined status, according to Kariv.

Workplace join doesn’t make the device join a domain but it does make the device known to Active Directory through a registration process so AD can issue the device a certificate for accessing applications. Workplace join is meant to give BYOD gear access to limited sets of corporate resources.

The service supports single sign-on for accessing multiple applications, and each application must be white listed for access by the service. Access can be controlled with combinations of user ID, device ID, and what network the device is connecting from, he says.

Authentication takes place at the proxy in a network demilitarized zone rather than at the application end of the network so is called pre-authentication. Pre-authentication methods include Kerberos Constrained Delegation (KCD), Microsoft Office Forms Based Authentication (MSO FBA) and OAuth. The proxy service also supports a pass-through option meaning there is no pre-authorization.

There are other authentication methods such as NTLM that Microsoft plans to support but hasn’t had the chance to yet, he says.

Proxying traffic to and from the applications blocks malformed packets and can mitigate Dos attacks Kariv says, by employing throttling and queuing.

The proxy can translate short internal URLs meant for reaching applications from within the firewall into full externally published URLs, eliminating the need to alter the internal addressing. It can also convert HTTPS traffic used externally to HTTP used internally.

It supports authentication methods including smartcards, PhoneFactor, and soft-password lockout.

Here are some of the differences between the on-prem deployment and the Azure AD Proxy Service.

Microsoft

The Active Directory service is physically located in the cloud, so published URLs for applications must be directed to the Azure service. Customers must install a connector from the application backend behind the corporate firewall to the application proxy server in Azure. The connection is an outgoing communication that keeps alive until the proxy receives incoming requests.

Catching malformed packets and dealing with DoS attacks against the Web applications are handled by Azure.

Web applications available through the proxy are listed on the Azure access panel that displays SaaS applications based in the cloud, so the Web apps can be found quickly and appear to end users as if they are physically based in Azure.

Workplace join and link translation aren’t available in the preview of Azure AD Proxy Service, but Microsoft is working on that, Kariv says.

Tim Greene covers Microsoft and unified communications for Network World and writes the Mostly Microsoft blog. Reach him at tgreene@nww.com and follow him on Twitter@Tim_Greene.