Publishing WEBCON BPS in Office 365 using Azure AD Application Proxy

Applies to version 2017.1.3.x; Author: Paweł Jawień

Since the release of Office 365, many companies changed their IT environments from typical ‘on premises’ environments (where all IT systems were localized in their owner’s server rooms) into hybrid environments. The difference is that now part of the services work based on local infrastructure and the other part is based on hosting infrastructure ex. Office 365.

In the case of hybrid infrastructure, some common challenges that should be addressed by the solution architects are:

  1. Establishing a safe connection between on-premises (local) infrastructure and cloud infrastructure.
  2. Ensuring SSO (single sign-on) to the users, so that from their point of view, moving between cloud and local applications is indistinguishable.

The following article describes a scenario in which WEBCON BPS system is installed on a local (on-premises) SharePoint installation, and is shared with users who usually use Office 365 services (ex. SharePoint o365 website).

Connecting/publishing the local SharePoint and WEBCON BPS with Office 365 was implemented by using the Azure Active Directory Application Proxy service (service is described in detail here:


Benefits of Azure AD Application Proxy


  • The published application doesn’t require any programming changes. SharePoint platform, as well as WEBCON BPS system (from 2017.1.x.x version), are compatible with Azure AD Application Proxy.
  • The user is provided with a coherent log-in system using SSO to Office 365 application and to applications released with Azure AD Application Proxy. Published applications are available to the user through their “My applications” portal ( and/or through Office 365 portal (



  • Applications published with Azure AD Application Proxy allow usage of additional access control mechanisms to applications delivered via Azure platform. E.g.: multifactor authentication.
  • It is not necessary to modify Firewall settings to allow incoming public internet traffic


The diagram below describes how on-premises applications released through Azure AD Application Proxy work.

Publishing method of local application (on premises) is described in detail here:


Configuration example:


In order to use Azure Active Directory Application Proxy it is needed to have at least Office 365 subscription as well as ‘Microsoft Azure Active Directory Basic’ service. In case of having Office 365 E3 or E5 subscription all elements needed for Azure AD Application Proxy are included in the package.


Preliminary assumptions:

  1. WEBCON BPS is installed locally on the SharePoint instance available in the internal corporate network under the address: http://demo-v5
  2. Users use Windows integrated authentication mechanisms when accessing http://demo-v5
  3. The company has Office 365 subscription purchased as wells as Microsoft Azure Active Directory Basic subscription.
  4. Users work mainly using the portal and/or
  5. Users will benefit from the ability to start WEBCON BPS directly from the MyApps portal without having to log-in to the system again.


Installation of Application Proxy Connector

In order to ensure safe publishing of the application from local network through Azure AD Application Proxy service, it is required to install Application Proxy Connector on the local network, on any machine with Windows Server 2012 R2 or Windows Server 2016.

Application installation and activation details are described in this article:


Configuration in Azure „cloud” (o365)

Cloud configuration of WEBCON BPS system publication has to be conducted by logging-in to the Azure portal ( with administrative privileges and go to Enterprise Applications


Create a new application using option: On-premises application.


In the window: Add your own on-premises application we define basic application parameters:

  • Name – the name by which the application will be available to the users of the o365 portal.
  • Internal URL address – SharePoint website address in local network (WEBCON BPS is installed on this website).
  • External URL address – field used to set a public URL address, which will allow access to the WEBCON BPS application through Azure AD Application Proxy service.
  • Pre Authentication – it’s required to choose a method of user authentication to the application. Choose “Azure Active Directory”.


After filling-in basic data and clicking on the Add button, a new application for the company will be generated and the system will move us to the view of detailed application configuration.

Correctly configuring the following three segments is very important:

  1. Users and groups
  2. Single sign-on
  3. Application proxy


The Users and groups tab requires you to provide accounts of the users who will get the access to the application through Azure AD Application Proxy.

In the Single sign-on tab, provide the SSO parameters which provide users with a log-in method integrated with Windows.

  • In the Single Sign-on mode field, choose Integrated authentication of Windows system.
  • The Internal application SPN field is used to input the service ID which will be used by the application Proxy server in order to ensure single sign-on. This log-in is also consistent with SPN registered to the server. In our case, it is: HTTP/demo-v5
  • In the field: Delegated Login Identity choose the type of the user identifier which will be sent to local Active Directory to authenticate. Choose User Principle Name (UPN).


Configuration in the local network

When publishing the SharePoint platform and WEBCON BPS system via Azure AD Application Proxy, the SharePoint server must be prepared to authenticate by using Kerberos Constrained Delegation (KCD).

This configuration is described in detail here:

Configuration order of the proposed installation example:

  1. Input SPN record for the SharePoint machine (machine name: demo-v5)

Run Command line with administrator privileges and then run the command:

SETSPN –S http/demo-v5 DEMO\svc.bps


  • http/demo-v5 is an identifier for SharePoint instance for Kerberos.
  • DEMO\svc.bps is a login used by the application pool of the SharePoint platform.


  1. SharePoint Web Application configuration in order to use Kerberos protocol
    • Go to the Central SharePoint Administration console
    • Go to option: Application Management -> Manage Web Application, choose main SharePoint website Web application and click on: Authentication Providers
    • In the section: Claims Authentication Types set: Negotiate (Kerberos)


  1. Active Directory configuration
    • Open the Active Directory User and Computer tool
    • Choose the server on which Application Proxy Connector is installed (in our example it’s on the server: DEMO-V4)
    • Use right mouse button to choose: Properties -> Delegation
    • In section: ‘Services to which this account can present delegated credentials’, it is required to add SPN value which was previously defined for the DEMO-V5 machine

It may be a good idea to set an alternative address for the site which contains the publishing URL in Azure AD Application Proxy (in this case: ). This is done in the Alternate Access Mappings page of the SharePoint Central Administration.

End result

Once the activities described above are carried out, the WEBCON BPS application is available to users with appropriate privileges, both from the MyApps portal as well as directly via URL address defined as the publishing address. In our installation, it is:


The application can also be found in the user’s application menu of their Office 365 panel.

2 thoughts to “Publishing WEBCON BPS in Office 365 using Azure AD Application Proxy”

  1. This option doesn’t seem to work with cross forest implementations unless I am missing something

    we are looking at resource-based constrained authentication

    1. Hello, could you provide more info? If the problem lies with Azure AD, then unfortunately there isn’t much we can do.

      Azure Application Proxy should work in multiforest environments, at least google says so.

Leave a Reply

Your email address will not be published. Required fields are marked *