When exposing SharePoint externally it is commonly desired to use a reverse proxy to act as a secure-endpoint for SharePoint. The primary purpose of this device or software-based application, is to carry out pre-authentication of connections to authenticate users first, and then only allowing authenticated users to access SharePoint. It essentially stops anonymous users gaining access to the servers hosting SharePoint without first being authenticated.
In addition to the purpose described above products such as Microsoft Threat Management Gateway (TMG) and Unified Access Gateway (UAG) are comprised of application inspection technologies, to further filter out unwanted traffic from directly communicating with applications such as SharePoint. The associated value of this kind of capability is somewhat questionable given the advancements in Operating System and Application specific security, perhaps a conversation for another time, but here’s an interesting insight from the Microsoft Exchange Product Group on their view of this technology, and how they secure their Exchange Online service in Office 365. UAG also includes a plethora of additional remote access technologies which are out of scope for this article but you can read more about them here.
TMG and UAG have been the technologies of choice for exposing SharePoint environments externally over recent times, however in late December 2013, Microsoft announced the retirement of UAG, but will still be providing extended support through to 2020. Prior to this announcement, at Tech-Ed New Orleans 2013, Microsoft announced the new Windows Server 2012 R2 feature – Web Application proxy (WAP). This feature is focused on browser and device based access with strong Active Directory Federation Services (AD FS) support. WAP isn't a complete replacement for all TMG/UAG scenarios but it does provide "secure application" publishing, allowing organizations to publish access to applications through a reverse-proxy integrating with AD FS for pre-authentication.
Utilizing WAP to securely publish SharePoint externally is a fully supported approach by Microsoft as documented here.
Before getting started with WAP, it's worth understanding some of the key pre-requisites. We won't repeat information listed elsewhere, but as mentioned earlier WAP is a Windows Server 2012 R2 feature and heavily relies on AD FS. The important nugget of information is that the AD FS instance associated with WAP must also be on a server (or servers) running Windows Server 2012 R2. The new version of AD FS included with Windows Server 2012 R2 is very different to its predecessor, and environments that encompass a perimeter network can utilize WAP servers as the proxy server rather than additional AD FS Proxy servers. This is illustrated and discussed further below.
So let's consider what an example topology may look like should you want to expose SharePoint web applications externally via WAP. Typically organizations with a desire to use a technology such as WAP would also want to place this server in a perimeter network, part of a separate domain. WAP supports such a topology, whilst still allowing the AD FS servers to be placed in the internal corporate network, as illustrated in the diagram below. In this example we can also see that our SharePoint farm is within the corporate network, for which we have a load balancer device configured for servers running the SharePoint web role. Similarly we have a load balanced AD FS service comprised of 2 servers. Although not illustrated in this diagram, it would also be possible to configure WAP in a load balanced configuration with two or more servers. Note that the WAP server here acts as the proxy to the AD FS servers located within the corporate network.
WAP supports a number of authentication methods and options, the correct choice will depend on your specific objectives and requirements. The Pass-through authentication method is where a client attempts to access SharePoint, and WAP forwards the request directly to SharePoint, and then SharePoint authenticates the request. If authentication is successful the client will have access to the published Web application. From a configuration perspective this is the simplest approach and it just works with default Claims based SharePoint web applications using NTLM authentication.
However if you've gone to the effort to deploy a reverse proxy, it's likely that you'll want to take advantage of the Pre-authentication through AD FS. With this approach, when a client attempts to access SharePoint, WAP forwards the request to AD FS with URL encoded parameters, and the users authenticated using the authentication method specified by AD FS (for example standard user name and password of two-factor authentication, and so on). After the user is authenticated, the AD FS server issues a security token containing information such as the user's identity, the SharePoint address and redirects the request back to WAP. WAP will then validate the token and if successful, will only then forward the request on to SharePoint, at which point the client now has access to the published web application and SharePoint authenticates the request. If authentication is successful the client will have access to the published Web application.
Taking advantage of Pre-authentication in WAP through AD FS will require that your SharePoint web applications are configured using Windows claims-based Kerberos authentication or SAML based claims. It would not be recommended to use SAML based claims unless you have other business requirements that direct you down this route. The alternative approach of using Kerberos authentication for SharePoint isn't something that should steer you away from using WAP for pre-authentication and is a requirement for a number of other SharePoint use cases. The configuration process for this is straightforward and relatively well documented now.
The final authentication approach that you may consider is a form of Client Certificate authentication using WAP to act as a reverse proxy for SharePoint hybrid capabilities with Office 365. More specifically those that require the inbound topology configuration to allow SharePoint sites in your Office 365 tenant to issue search queries to your on-premises farm once a trust has been established. This approach requires that you upload a certificate to the Secure Store Service Application in your Office 365 tenant and publish your SharePoint web application through WAP using the same certificate, and is discussed in much more detail here.
What else does WAP offer?
With the ever-growing importance of remote access to SharePoint, ensuring that you can keep people connected to information when they are working from home or on the road from varying devices, there are a number of challenges to consider. There's increased risk around the management of devices (personal or corporate), as well as the risk of data loss through device loss. The overall security challenge is arguably greater than ever before when considering remote access to SharePoint.
Existing solutions encompassing VPN, Direct Access and Reverse Proxies help to mitigate this risk but WAP specifically targets the challenges around mobile devices in the modern workplace. WAP introduces a feature called Workplace Join which allows users to join devices to the workplace that would not normally be domain-joined, for example personal laptops, tablets, and mobile phones. When this feature is configured, it is possible to ensure devices are registered and valid before they can gain access to published applications such as SharePoint. Furthermore this technology allows for SSO from the aforementioned devices allowing users to enter credentials only once to be authenticated against all published applications. Registration of devices can be revoked by the organization at any time as and when required. At the current time supported devices include iOS based devices and devices running Windows 8.1.
In addition to this, WAP supports Multifactor authentication as mentioned briefly above. AD FS can be configured to require users to authenticate with more than one authentication scheme for example a one-time password or a smart card in addition to standard credentials. On a similar note, WAP can take advantage of AD FS Multifactor access control allowing authorization claims rules to be created to permit or deny access to SharePoint to users and groups based on claims attributes.
Hopefully this post gives you an overview of the new capabilities of the Web Application Proxy (WAP) feature in Windows Server 2013 R2 and how it can be utilized by your SharePoint 2013 environments to securely publish your sites externally. In the next post, which you can access via the button below, we will take a look at the end-to-end configuration process of WAP using pre-authentication for Windows claims-based SharePoint web applications.