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 = "zastąp dowolnym tekstem w celu zabezpieczenia ciasteczka"
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.
- 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.
