Publishing WEBCON BPS in public Internet using Reverse Proxy with pre-authentication

Applies to version: 2020.1.x; author: Tomasz Słuszniak

 

 

Introduction

This article describes one of the possible methods of publishing the content of the WEBCON BPS platform on the generally accessible Internet, maintaining the physical separation of the server hosting the platform. The use of firewalls and Reverse Proxy provides a security buffer in the case of e.g. DDoS attacks. Reverse Proxy acts as a physical buffer that filters external traffic, and takes on the possible effects of external attacks. Thanks to this solution, the server located in the internal network is not affected by potential attacks, or at least their consequences are mitigated. 

The pre-authentication mechanism allows you to provide an additional level of traffic filtration that comes from the public internet network and will prevent anonymous access to the WEBCON BPS Portal resources.  

 

 

Tools use in this article

• nssm (version 2.24) – installation and configuration of Windows services
• nginx (version 1.18.0) – www server
• oauth2-proxy (version 6.1.1) – proxy server that ensures the authentication with the external providers (Azure AD, Google)

Assumptions

• WEBCON BPS is installed in the internal network
• WEBCON BPS Portal uses one of the available login mechanisms e.g. Azure AD, Google – BPS Auth

Preparation

As an example, a configuration with Azure AD authentication was presented. The configuration for other providers is available in the official project documentation https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider.

 

nnsm installation

nssm is used as a tool for installation nginx and oauth2-proxy as a Windows service. Nssm is available at https://nssm.cc/download. Unpack the downloaded package and place in the C:nssm location.

 

Oauth2-proxy installation

Oauth2-proxy can be run in the system as a service or as a container.  

1. Installation as Windows Service

Oauth2-proxy installation is available at https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v6.1.1. Unpack the downloaded *.tar.gz package to C:\oauth2-proxy.

Use nssm tool for installation.

.\nssm.exe install oauth2-proxy "C:\oauth2-proxyoauth2-proxy"

.\nssm.exe set oauth2-proxy AppDirectory "C:oauth2-proxy"

.\nssm.exe set oauth2-proxy Start SERVICE_AUTO_START

.\nssm.exe set oauth2-proxy AppParameters "--config=C:\oauth2-proxy\oauth2-proxy.cfg"

.\nssm.exe start oauth2-proxy

 

Configuration

In the C:\oauth2-proxy  location, create the “oauth2-proxy.cfg” configuration file. The minimum configuration is as follows:

provider = "azure"

client_id = "<client_id>"

client_secret = "<client_secret>"

redirect_url = "https://at14.webcon.pl/oauth2/callback"

 

cookie_secret = "here, insert any text you like to secure the cookie"

cookie_secure = true

cookie_samesite = "none"

session_cookie_minimal = true

 

reverse_proxy = true

http_address = "0.0.0.0:4180"

email_domains = ["*"]

 

The yellow text fragments should be replaced according to the Azure Portal and WEBCON BPS configuration.

The configuration in the Azure portal is presented in the project documentation -> https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#azure-auth-provider.

The website operation can be verified by going to the address http://127.0.0.1:4180 in the browser.

The running application should display the following content:

 

 

2. Docker (Linux)

To run oauth2-proxy in the container first, create the „oauth2-proxy.cfg” file – it may be the same as for the installation as a Windows service in step 1.

Place this file in the /var/www/oauth2-proxy location.

docker run --name oauth2-proxy --restart unless-stopped -p 4180:4180 -v "/var/www/oauth2-proxy/oauth2-proxy.cfg:/oauth2-proxy.cfg" -d quay.io/oauth2-proxy/oauth2-proxy:v6.1.1 "--config=/oauth2-proxy.cfg"

The service operation can be verified by going to the address http://127.0.0.1:4180 in the browser.

The running application should display the following content:

 

 

3. Google authentication

The Azure AD authentication presented in step 1 of the oauth2-proxy installation should be slightly modified. You must change only three parameters:

provider = "google"

client_id = "<client_id>"

client_secret = "<client_secret>"

 

More information about Google configuration is described in the project documentation -> https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#google-auth-provider.

 

Nginx installation

Nginx can also be run as a system service or as a container.

1. Installation as Windows Service

For installation we will use the Nssm tool, just like in the case of oauth2-proxy.

.\nssm.exe install nginx "C:\nginxnginx.exe"

.\nssm.exe start nginx

 

The nginx operation can be verified by going to the address http://127.0.0.1 in the browser.

The running nginx should display the following content:

 

 

 

Configuration

In the C:\nginx\conf\ location, there is a “nginx.conf” configuration file  - edit this file. The minimum configuration should be as below:

worker_processes  1;

events {

    worker_connections  1024;

}

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

 

    proxy_busy_buffers_size   512k;

    proxy_buffers   4 512k;

    proxy_buffer_size   256k;

 

    large_client_header_buffers 4 32k;

    server {

        listen       80;

        server_name  at14.webcon.pl www.at14.webcon.pl;

        return 301 https://$server_name$request_uri;

    }

    server {

        listen 443 default ssl;

        server_name at14.webcon.pl www.at14.webcon.pl;

 

        ssl_certificate C:/nginx/cert/webcon.crt;

        ssl_certificate_key C:/nginx/cert/webcon.rsa;

        add_header Strict-Transport-Security max-age=2592000;

 

        location /oauth2 {

            proxy_pass http://127.0.0.1:4180;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Scheme $scheme;

            proxy_connect_timeout 1;

            proxy_send_timeout 30;

            proxy_read_timeout 30;

        }

        location / {

            auth_request /oauth2/auth;

            error_page 401 = /oauth2/sign_in;

            proxy_pass http://at14.webcon.pl:8080;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Scheme $scheme;

            proxy_connect_timeout 1;

            proxy_send_timeout 30;

            proxy_read_timeout 30;

        }

    }

}

 

The yellow text fragments should be replaced according to the current installation.

In the location /”, the proxy_pass parameter should be set to the address where WEBCON BPS Portal is available in the internal network.

In the C:\nginx, create the cert directory with the *.crt and *.rsa SSL certificate files for a domain where the nginx file will be provided.

 

2. Docker (Linux)

The configuration file for nginx running in Docker will be almost identical to the installation as Windows Service (point 1) except for the certificate paths.

Place the “nginx.conf” file in the /var/www/nginx/ location. The *.crt certificate with the *.rsa key put in the /var/www/nginx/cert/.

Two lines should be replaced:

ssl_certificate /etc/nginx/cert/webcon.crt;

ssl_certificate_key /etc/nginx/cert/webcon.rsa;

 

Command:

docker run --name nginx -v "/var/www/nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro" -v "/var/www/nginx/cert:/etc/nginx/cert:ro" -p 80:80 -p 443:443 -d nginx

 

Verification

The operation of nginx + oautch2-proxy can be verified by going to the address set in server_name (in this case - https://at14.webcon.pl).

The running nginx with oauth2-proxy should display the following content:

 

 

To log in, click the “Sign in with Azure”.

There is also the ability of skipping the Provider selection step – in the “oauth2-proxy.cfg” configuration file, add the following option:

skip_provider_button = true

 

Logging in via Azure AD in oauth2-proxy will result in the user not having to log in a second time in WEBCON BPS Portal. They will be logged in automatically.

 

Attention!

The presented configuration is only an example that allows you to present one of the possibilities of publishing WEBCON BPS Platform on the public intranet. The configuration is not a producent’s recommendation as to how publish it, nor is it a model for the used configurations.