Publishing SharePoint-Hosted Apps with Web Application Proxy

To continue the SharePoint on Web Application Proxy theme, something that’s not been covered yet is how to publish SharePoint-hosted applications with Web Application Proxy, in particular with single-sign-on (via ADFS) to make sure we only authenticate users once for any URL. It’s a legitimate question given SharePoint & SharePoint app URLs are different by design so there’s a bunch of extra considerations that need to be taken into account.

Here’s what we want to accomplish, as I’ve managed on a test environment:

We want to publish SharePoint-hosted applications so that users outside the internal network can access SharePoint-hosted applications with the same authentication they access normal SharePoint site with. The user should only have to login once for both domains in other words.

We assume that the URLs are the same both internally & externally, and that you’ve got a working ADFS with SharePoint working already. If you’ve not set this up, then you need to do so & familiarise yourself with this architecture first.

SSL Certificates Needed

The first thing to take into account is the SSL certificate you’ll need as Web Application Proxy is HTTPS only. No HTTP only here; SSL all the way, so this in itself is something that’ll need some studying to make sure you don’t get certificate validation errors when you try and access any part of SharePoint.

In short, the certificate that WAP/SharePoint will use will need to be valid for app URLs too. Normally that means adding a wildcard common-name for all possible apps – “CN =*.apps.contoso.com” for example, in addition to the normal common-names in the certificate (“CN = sharepoint.contoso.com”).

Remember of course that when you setup Web Application Proxy, you give a separate certificate then for the ADFS bit so you just need to two domains for the application publishing certificate.

Default HTTPS Website in SharePoint

You’ll also need SharePoint setup with a default 443 IIS site – at least one default-header, non Server Name Indication (SNI) site as the app-URL will obviously not match the normal SharePoint hostname, so if your IIS site has host-headers then the connection for your app URL (apps*.contoso.com for example) will never work for an SNI-enabled IIS site for a normal SharePoint header (sharepoint.contoso.com for example) – IIS would reject the connection because the headers wouldn’t match. Because of this, we need a single “one-size-fits all” SSL site for apps + normal SharePoint SSL.

For the record, I only managed to get this setup working when my HTTPS site was the default zone, but I’ve not yet confirmed why exactly. If you’re having issues, after authenticating back from ADFS then make sure your default zone site is the only SSL site.

Publish Applications in Web Application Proxy

Next up, we need to publish the URLs in Web Application Proxy. For both the normal application URL and any application URL, you need to do the same:

Each URL needs to use the ADFS server configured.

Also the same relying party in said ADFS server.

Make sure both URLs are the same, and we select the right certificate – the one that’s valid for both the normal site URL + SharePoint apps wildcard.

That’s pretty much it! Once done your WAP console should look something like this:

We should now be done with Web Application Proxy.

Configure WReply on the ADFS Identity Provider

You’ll need to enable WReply on the SPTrustedIdentityTokenIssuer that you’ve already configured in SharePoint by running this PowerShell (changing the “Name” of course):

$ap =Get-SPTrustedIdentityTokenIssuer “Name”

$ap.UseWReplyParameter = $true

$ap.Update()

Also, in the ADFS relying-partner you’ve already configured you need to add a wildcard WS-Federation endpoint like so:

Once done, ADFS can now authenticate for both normal & (any) app domains.

Testing SharePoint App Access via Web Application Proxy

Once it’s all in place, from outside we go to the normal URL, where we get sent to ADFS (via the proxy) to login.

Here we log-in like normal; from externally the ADFS DNS is pointing at the WAP server of course.

…and now we’re into the SharePoint site. Click the application link:

Here’s the magic bit: no authentication prompt when we redirect, despite being a different domain – the existing token is valid!

User identity has carried over just fine - job done!

Wrap-Up

Once this is all running, your Web Application Proxy + ADFS will now be able to authenticate for any app published only authenticating once. It’s not particularly simple, but it is possible

Cheers,

Sam Betts

Comments

• Anonymous
  June 10, 2016
  Hi Sam, Nice article! However,I think your setup would only work if you stick with the same SP Url's. In the case of host named site collections, where you could have a new hostheader at any time, it would be a problem. Or you would have to renew the certificate and update it with the additional host headers. Do do you have any idea if WAP can support SNI somehow and allows you to bind multiple certificates to a single IP address?Thanks!Hans