Publikacja WEBCON BPS w publicznym internecie z użyciem Reverse Proxy z preautentykacją

Facebooktwitterpinterestlinkedinmail
Dotyczy wersji 2020.1.3.321 autor: Tomasz Słuszniak

 

Wprowadzenie

Przedstawione w artykule rozwiązanie jest jedną z możliwych metod publikacji zawartości platformy WEBCON BPS w ogólnie dostępnym internecie z zachowaniem separacji fizycznej serwera hostującego platformę WEBCON BPS.  Zastosowanie  firewalli oraz Reverse Proxy zapewnia bufor bezpieczeństwa w przypadku np. ataków DDoS. Reverse Proxy pełni rolę fizycznego bufora filtrującego ruch zewnętrzny i przyjmuje na siebie ewentualne skutki ataków zewnętrznych. Dzięki takiemu rozwiązaniu serwer umieszczony w sieci wewnętrznej nie odczuwa (lub odczuwa w stopniu minimalnym) efektów potencjalnych ataków.

Zastosowanie mechanizmu preautentykacji na poziomie Reverse Proxy, zapewnia dodatkowy poziom filtracji ruchu przychodzącego z publicznej sieci internet oraz uniemożliwi anonimowy dostęp do zasobów Portalu WEBCON BPS.

 

Narzędzia wykorzystane w artykule

  • nssm (wersja 2.24) – instalacja i konfiguracja usług Windows
  • nginx (wersja 1.18.0) – serwer www
  • oauth2-proxy (wersja 6.1.1) – serwer proxy zapewniający autentykację za pomocą zewnętrznych dostawców (Azure AD, Google).

Założenia

WEBCON BPS Portal zainstalowany w sieci wewnętrznej.

W Portalu WEBCON BPS wykorzystywany jest jeden z dostępnych mechanizmów logowania (np. Azure AD, Google – BPS Auth).

Przygotowanie

Jako przykład przedstawimy konfigurację z autentykacją Azure AD. Konfiguracja dla innych dostawców autentykacji dostępna jest w oficjalnej dokumentacji projektu: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider

 

Instalacja nssm

Nssm posłuży nam jako narzędzie do instalacji nginx oraz oauth2-proxy jako Usługa Windows. Nssm dostępny jest pod adresem: https://nssm.cc/download. Pobraną paczkę należy rozpakować i umieścić w lokalizacji C:\nssm.

 

Instalacja oauth2-proxy

Oauth2-proxy możemy uruchomić w systemie jako usługa lub jako kontener.

1.Instalacja jako Windows Service

Aplikacja oauth2-proxy dostępna jest pod adresem https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v6.1.1. Pobraną paczkę *.tar.gz. należy rozpakować do lokalizacji C:\oauth2-proxy

Do instalacji należy wykorzystać narzędzie nssm.

.\nssm.exe install oauth2-proxy „C:\oauth2-proxy\oauth2-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

 

Konfiguracja

W lokalizacji C:\oauth2-proxy należy utworzyć plik konfiguracyjny o nazwie „oauth2-proxy.cfg”. Minimalna konfiguracja pliku wygląda następująco:

provider = „azure”

client_id = „<client_id>

client_secret = „<client_secret>

redirect_url = „https://at14.webcon.pl/oauth2/callback”

 

cookie_secret = „webcon1234567890

cookie_secure = true

cookie_samesite = „none”

session_cookie_minimal = true

 

reverse_proxy = true

http_address = „0.0.0.0:4180”

email_domains = [„*”]

 

Należy podmienić oznaczone na żółto fragmenty tekstu zgodnie z konfiguracją w Azure Portal i WEBCON BPS.

Opis konfiguracji w Azure Portal przedstawiony został w dokumentacji projektu: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#azure-auth-provider

Weryfikacji działania Serwisu możemy dokonać przechodząc w przeglądarce na adres http://127.0.0.1:4180.

Działająca aplikacja powinna wyświetlić poniższą zawartość:

 

2. Docker (w systemie Linux)

Aby uruchomić oauth2-proxy w kontenerze należy w pierwszej kolejności przygotować plik „oauth2-proxy.cfg”. Plik może być identyczny jak dla instalacji jako usługa Windows w punkcie 1.

Plik należy umieścić w lokalizacji /var/www/oauth2-proxy/.

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”

Weryfikacji działania Serwisu możemy dokonać przechodząc w przeglądarce na adres http://127.0.0.1:4180.

Działająca aplikacja powinna wyświetlić poniższą zawartość:

 

3. Przykład konfiguracji dla autentykacji Google

Konfigurację autentykacji Azure AD przedstawiona w punkcie 1 instalacji oauth2-proxy należy nieznacznie zmodyfikować. Zmiana dotyczy jedynie 3 parametrów:

provider = „google”

client_id = „<client_id>”

client_secret = „<client_secret>”

Więcej informacji, wraz ze szczegółami konfiguracji po stronie Google opisane jest w dokumentacji projektu: https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#google-auth-provider

 

Instalacja nginx

Podobnie jak w przypadku oauth2-proxy, nginx również może być uruchomiona jako usługa systemowa lub jako kontener.

  1. Instalacja jako Windows Service

Do instalacji wykorzystamy podobnie jak w przypadku oauth2-proxy narzędzie Nssm.

.\nssm.exe install nginx „C:\onginx\nginx.exe”

.\nssm.exe start nginx

Działanie nginx można zweryfikować przechodząc w przeglądarce na adres http://127.0.0.1. Działający nginx powinien wyświetlić zawartość:

 

Konfiguracja

W lokalizacji C:\nginx\conf\ znajduje  plik konfiguracyjny o nazwie nginx.conf. Plik należy edytować, a minimalna konfiguracja powinna wyglądać jak poniżej.

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;

        }

    }

}

 

Należy podmienić oznaczone na żółto fragmenty dostosowując do bieżącej instalacji.

W sekcji „location /” parametr proxy_pass powinien mieć ustawiony adres, pod którym dostępny jest WEBCON BPS Portal w sieci wewnętrznej.

W lokalizacji C:\nginx należy utworzyć katalog cert, a w nim należy umieścić pliki *.crt oraz *.rsa certyfikatu SSL dla domeny, pod którą udostępniony będzie publicznie nginx.

 

2. Docker (w systemie Linux)

Plik konfiguracyjny dla nginx działającego w Dockerze będzie prawie identyczny jak w przypadku instalacji jako Windows Service (punkt 1) poza ścieżkami do certyfikatów.

Plik „nginx.conf” należy umieścić w lokalizacji /var/www/nginx/. Certyfikat *.crt wraz z kluczem *.rsa w lokalizacji /var/www/nginx/cert/.

Należy podmienić dwie linijki:

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

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

Polecenie:

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

 

Weryfikacja działania

Działanie nginx + oauth2-proxy można zweryfikować przechodząc w przeglądarce pod adres ustawiony w server_name, w naszym przypadku https://at14.webcon.pl.

Poprawnie działający nginx wraz z oauth2-proxy powinien wyświetlić zawartość:

 

Aby zalogować się, należy kliknąć przycisk „Sign in with Azure” i zostaniemy przekierowani na stronę logowania Microsoft.

Istnieje również możliwość pominięcia kroku wyboru Dostawcy, w tym celu w pliku konfiguracyjnym „oauth2-proxy.cfg” należy dodać dodatkową opcję:

skip_provider_button = true

Zalogowanie się za pomocą Azure AD w oauth2-proxy spowoduje, że użytkownik nie będzie musiał logować się drugi raz w WEBCON BPS Portal. Zostanie zalogowany automatycznie.

 

UWAGA!

Przedstawiona konfiguracja jest tylko działającym demonstratorem technologii, który ma na celu przedstawienie jednej z możliwości publikacji platformy WEBCON BPS w publicznym intranecie. Konfiguracja nie jest zaleceniem producenta co do sposobów publikacji, nie jest też wzorem dla stosowanych konfiguracji.