Przygotowanie infrastruktury na środowisku OnPremises
Aplikacja zbudowana na platformie VSoft archITekt do swojego działania produkcyjnego wymaga następujących komponentów:
Serwer aplikacyjny (pojedynczy lub klaster):
- Serwer fizyczny lub maszyna wirtualna.
- System operacyjny Windows 2019 lub Windows 2022 z zainstalowanymi wszystkimi poprawkami krytycznymi i bezpieczeństwa.
- Zainstalowany VSoft archITekt Image w wersji, na której zbudowana jest instalowana aplikacja.
- Serwer aplikacyjny ma otwarty ruch do serwera bazodanowego (domyślnie port 1433 dla MS SQL Server lub port 5432 dla PostgreSQL).
- Użytkownik instalujący aplikację musi mieć uprawnienia administracyjne na serwerze.
Aplikacja może działać na jednym z dwóch silników bazodanowych: MS SQL Server lub PostgreSQL. Silnik wybiera się podczas instalacji parametrem dbServerProvider.
Serwer bazodanowy MS SQL Server:
- MS SQL Server 2019 lub nowszy.
- Edycja silnika bazy danych: SQL Express lub wyższa.
- Zainstalowana funkcja wyszukiwania pełnotekstowego (Full-Text Search) w SQL Server.
- Użytkownik instalujący aplikację musi mieć uprawnienia administracyjne na serwerze bazodanowym (musi mieć uprawnienia pozwalające zakładać bazy i użytkowników na serwerze).
- W przypadku instalacji aplikacji na kontach systemowych SQL Server musi mieć włączoną możliwość zalogowania się za pomocą loginu i hasła (Mixed Mode Authentication).
Serwer bazodanowy PostgreSQL:
- PostgreSQL w wersji objętej wsparciem społeczności PostgreSQL (lista wspieranych wersji i daty zakończenia ich wsparcia: https://www.postgresql.org/support/versioning/). Zalecana jest wersja 16 lub nowsza – na wersjach 16, 17 i 18 platforma VSoft archITekt jest testowana.
- Wystarczająca jest standardowa (community) dystrybucja PostgreSQL. Nie są wymagane żadne dodatkowe rozszerzenia (extensions) ani słowniki wyszukiwania pełnotekstowego.
- Klaster bazy danych powinien używać kodowania UTF8. Instalator nie podaje kodowania ani collation przy zakładaniu baz – bazy dziedziczą ustawienia z szablonu
template1. - Użytkownik instalujący aplikację musi być superużytkownikiem serwera PostgreSQL (np.
postgres). Instalator zakłada role i bazy danych, przekazuje własność baz innym rolom i nadaje uprawnienia domyślne (default privileges) w imieniu innych ról. - Musi istnieć baza
postgres, a użytkownik instalujący aplikację musi mieć do niej dostęp. Instalator używa jej do weryfikacji połączenia z serwerem. - Aplikacja łączy się z bazą danych wyłącznie za pomocą loginu i hasła (
applicationDbAuthentication=UserPassword). Uwierzytelnianie Windows nie jest obsługiwane. - Serwer musi przyjmować połączenia TCP (parametr
listen_addressesw plikupostgresql.conf). W plikupg_hba.confnależy zezwolić na logowanie hasłem (zalecana metodascram-sha-256) z serwerów aplikacyjnych i z komputera, z którego uruchamiana jest instalacja. - Parametr
max_connectionsnależy dobrać do liczby serwerów aplikacji. Każdy proces aplikacji utrzymuje własne pule połączeń do baz CONFIG, DATA i SCHEDULER. Dla typowego wdrożenia jednoserwerowego wystarcza wartość 200. - Wymagany jest plikowy serwer wersji (
versionProvider=FileSystem). Bazodanowy serwer wersji nie jest dostępny dla PostgreSQL.
Informacje dodatkowe:
Środowisko zakłada, że każdy serwer może należeć do jednej lub obu poniższych grup:
- Web – instalowane na nim są komponenty WWW
- App – instalowane na nim są serwisy Windows
W przypadku instalacji na środowisku jednoserwerowym należy założyć, że serwer należy do obu tych grup (obie grupy komponentów zostaną zainstalowane na tym samym serwerze).
W przypadku instalacji na środowisku klastrowym można dowolnie przyporządkowywać serwery do grup.
- Instalator VSoft archITekt Image automatycznie instaluje wszystkie wymagane przez niego komponenty (m.in. .NET Framework).
- W momencie instalacji docelowej aplikacji na serwerze, mechanizm instalacyjny automatycznie włączy wymagane role systemu Windows (oddzielny zestaw ról w zależności od tego, do której grupy należy dany serwer: Web czy App).
Instalator docelowej aplikacji:
- na serwerach grupy Web automatycznie instaluje serię aplikacji WWW obsługiwanych przez IIS,
- na serwerach grupy App automatycznie instaluje serię serwisów Windows,
- na serwerze bazodanowym automatycznie zakłada dedykowanych użytkowników i bazy danych aplikacji.
Zakres danych technicznych wymaganych do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwer bazodanowy | Adres instancji | dbServer | np. mydbserver\SQLEXPRESS (MS SQL Server) lub mydbserver (PostgreSQL) |
| Użytkownik | dbUser | Niewymagane jeśli używany jest użytkownik domenowy. | |
| Hasło | dbPassword | Niewymagane jeśli używany jest użytkownik domenowy. | |
| Serwer aplikacyjny | Nazwa serwera | targetAppServers targetWebServers | Nazwa komputera (hostname). |
| Początek bloku zarezerwowanych portów. | reservedPortsBlockBegin. | Np. 48000 | |
| Nazwa pod jaką serwer aplikacyjny widziany jest w sieci. | appServerFQDNAddress webServerFQDNAddress | np. myserver.local.domain |
Wyjaśnienia:
Początek zarezerwowanego bloku portów wewnętrznie używanych przez aplikację (np. 48000)
- Żadna inna aplikacja nie może korzystać z któregokolwiek portu z zarezerwowanego bloku.
- Aplikacja używa wewnętrznie blok o rozmiarze „2 + N” portów, gdzie N to liczba uruchomionych konwerterów serwisu generacji dokumentów (domyślnie jest uruchomiony 1 konwerter).
- Dla typowych wdrożeń produkcyjnych sugerowane jest zarezerwowanie 10 portów na potrzeby aplikacji.
W przypadku instalacji zdalnej aplikacji
W przypadku, gdy użytkownik instaluje aplikację ze swojego komputera na serwerze w sposób zdalny wymagane jest aby:
- Z komputera użytkownika był otwarty ruch do serwera bazodanowego (domyślnie port 1433 dla MS SQL Server lub port 5432 dla PostgreSQL).
- Z komputera użytkownika był otwarty ruch do serwera aplikacyjnego poprzez PS Remoting (domyślnie na porcie 5985).
- Na serwerze aplikacyjnym był włączony PS Remoting.
Włączenie PS Remoting na serwerze a pomocą polecenia PowerShell:
Enable-PSRemoting
W przypadku instalacji zdalnej aplikacji na komputerze poza domeną
W przypadku instalacji zdalnej na serwerze poza domeną, na komputerze, z którego uruchomiona zostanie instalacja zdalna należy:
- dodać serwer aplikacyjny do komputerów zaufanych, aby można było połączyć się z nim za pomocą PS Remoting.
Dodanie serwera do komputerów zaufanych dla PS-Remoting (Uwaga: należy uruchomić PowerShell z prawami administratora):
Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>;[,<ComputerName>]
gdzie <ComputerName> to adres nazwa lub IP serwera lub * (* oznacza dowolny adres)
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwer aplikacyjny | Nazwa lub adres IP serwera | targetAppServers targetWebServers | Na ten adres będzie wykonywane połączenie za pomocą PS-Remoting. |
Wyjaśnienia
Wartość parametrów targetAppServers i targetWebServers w przypadku, gdy instalujemy aplikację poza domeną i nie ma możliwości połączenia się z serwerem za pomocą jego nazwy („computername”) należy podawać w formacie <computername>:<name or ip address>, gdzie <name or ip address> oznacza adres używany do połączenia z serwerem za pomocą PS-Remoting.
Przykład użycia:
-targetAppServers "myserver4:13.95.136.102" - targetWebServers "myserver5:40.68.91.205"
W przypadku instalacji z użyciem certyfikatów SSL
W przypadku instalacji aplikacji korzystającej z protokołu https (zabezpieczonego certyfikatami SSL) wymagane jest:
umieszczenie na serwerze certyfikatu SSL:
- w kontenerze „LocalMachine\My”
- wraz z kluczem prywatnym
- wystawionego na nazwę pod jaką serwer aplikacyjny będzie widziany w sieci
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwer aplikacyjny | Rodzaj zabezpieczenia | securityMode | SSL |
| Odcisk certyfikatu | appServer_HttpsCertificate webServer_HttpsCertificate | Thumbprint użytego certyfikatu SSL |
Przykład użycia:
-appServer\_HttpsCertificate "0000000000000000000000000000000000000000"
Informacje dodatkowe:
- W niektórych wersjach systemu Windows podczas kopiowania thumbpirnt certyfikatu z okna systemowego kopiowany jest niedrukowalny znak na początku tekstu. Należy pamiętać, aby go usunąć.
Dobre praktyki
W przypadku użycia protokołu SSL dobrą praktyką jest również włączenie flagi HSTS (HTTP Strict Transport Security) dla danej strony internetowej. Flaga wymusza na przeglądarce użytkownika połączenie z daną stroną internetową wyłącznie za pomocą protokołu HTTPS .
Ustawienie tej flagi wpływa na wszystkie aplikacje działające na danej stronie internetowej. Połączenie z każdą z nich będzie możliwe wyłącznie za pomocą protokołu HTTPS.
Flagę HSTS w serwerze IIS można włączyć:
- korzystając z modułu zarządzania konfiguracją IIS
- albo korzystając ze skryptu PowerShell
Import-Module WebAdministration
$siteName = "Default Web Site"
Set-ItemProperty "IIS:\Sites\$siteName\" -Name "HSTS.enabled" -Value $true
Set-ItemProperty "IIS:\Sites\$siteName\" -Name "HSTS.max-age" -Value 31536000
Set-ItemProperty "IIS:\Sites\$siteName\" -Name "HSTS.includeSubDomains" -Value $true
Set-ItemProperty "IIS:\Sites\$siteName\" -Name "HSTS.redirectHttpToHttps" -Value $true
Wskazane jest również zainstalowanie mechanizmu przekierowywującego ruch z http na https w serwerze IIS za pomocą dodatku UrlRewrite. W tym celu należy:
- Zainstalować dodatek UrlRewrite ze strony https://www.iis.net/downloads/microsoft/url-rewrite
- Dodać w głównym katalogu IIS plik konfiguracyjny C:\inetpub\wwwroot\Web.Config o treści:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect to https" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
W przypadku instalacji, która ma działać na koncie domenowym
Aplikacje domyślnie używają standardowych wbudowanych kont systemu Windows do uruchamiania puli aplikacji WWW i serwisów Windows. Instalowana aplikacja może także działać na wskazanym koncie domenowym, w tym celu należy przekazać informacje o tym koncie.
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwer aplikacji | Nazwa użytkownika domenowego | applicationCredentialUser | W formacie DOMENA\uzytkownik |
| Hasło użytkownika domenowego | applicationCredentialPassword | ||
| Baza danych | Sposób autentykacji aplikacji w bazie danych | applicationDbAuthentication | Wybór jednej z wartości: UserPassword lub Windows |
Konfiguracja serwera baz danych
W przypadku korzystania silnika bazodanowego MS SQL Server nie jest wymagana dodatkowa konfiguracja.
W przypadku korzystania silnika bazodanowego PostgreSQL należy:
- Zmodyfikować plik
pg_ident.confdodając mapowanie użytkowników lokalnych oraz użytkowników domeny na konta PostgreSQL zgodnie z dokumentacją silnika bazy danych.
Poniżej prezentowany jest przykład dodania mapowania dla domeny MYDOMAIN w pliku pg_ident.conf
Poniższa reguła spowoduje, że nazwy użytkowników w bazie danych tworzone są na podstawie nazw użytkowników domenowych z pominięciem suffixu w postaci nazwy domeny (czyli „sample.user@mydomain” zostanie zmapowany na użytkownika bazodanowego „sample.user”)
Nazwę domeny można uzyskać uruchamiając polecenie PowerShell $env:USERDOMAIN
- Zmodyfikować plik
pg_hba.confdodając regułę autentykacji zdefiniowaną w poprzednim punkcie.
Poniżej prezentowany jest przykład dodania reguły autentykacji z poprzedniego punktu do pliku pg_hba.conf
Zmiany konfiguracji zostaną uwzględnione po restarcie serwera bazodanowego.
Wyjaśnienia
W przypadku uruchomienia komponentów aplikacji na koncie domenowym możliwe jest połączenie aplikacji z bazą danych za pomocą autentykacji Windows. W tym przypadku instalator nie tworzy dedykowanych kont użytkowników na serwerze bazodanowym.
W przypadku instalacji na środowisku klastrowym
Aplikacje mogą być zainstalowane na środowisku klastrowym, opcjonalnie możliwe jest również rozdzielenie komponentów warstw prezentacji (web) i aplikacyjnej (app) na oddzielne grupy serwerów.
Każdy serwer może należeć zarówno do jednej wybranej lub do obu grup.
W przypadku instalacji na środowisku klastrowym każdy serwer musi spełniać wymagania jak w przypadku instalacji na środowisku jednoserwerowym – opisanym na początku rozdziału.
Instalacja na środowisku klastrowym wymaga dodatkowo:
- Otworzenia ruchu pomiędzy serwerami dla zarezerwowanego bloku portów wykorzystywanych do komunikacji wewnętrznej przez aplikację.
- Utworzenia adresów klastrowych dla obu grup serwerów.
- Konfiguracji LoadBalanera na serwerach grupy Web. W tym celu można użyć wbudowanego LoadBalancera systemu Windows lub skorzystać z rozwiązania firm trzecich.
- Konfiguracji klastra fileover na serwerach grupy App.
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwery warstwy Web | Nazwa pod jaką serwery warstwy Web widziane są w sieci. | webServerFQDNAddress | np. webserver.local.domain |
| Nazwy wszystkich serwerów w tej grupie. | targetWebServers | Nazwa komputera (hostname) | |
| Serwery warstwy App | Nazwa pod jaką serwery warstwy App widziane są w sieci. | appServerFQDNAddress | np. appserver.local.domain |
| Nazwy wszystkich serwerów w tej grupie. | targetAppServers | Nazwa komputera (hostname) |
W przypadku korzystania z funkcjonalności automatycznego wysyłania maili
W przypadku, gdy instalowana aplikacja końcowa korzysta z funkcjonalności automatycznego wysyłania e-maili wymagane jest skonfigurowania połączenia SMTP.
Wymagane jest:
- Otworzenie ruchu z poziomu serwerów grupy App do serwera pocztowego na porcie wykorzystywanym przez SMTP.
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Serwer SMTP | Adres serwera pocztowego SMTP | configKeys/ common.param.smtp_server | |
| Port usługi SMTP | configKeys/ common.param.smtp_port | Domyślna wartość: 25 | |
| Sposób zabezpieczenia połączenia | configKeys / common.param.smtp_security | Domyślna wartość: Auto Dopuszczalne wartości: None, Auto, SslOnConnect, StartTls, StartTlsWhenAvailable | |
| Flaga pozwalająca ignorować niektóre błędy certyfikatu serwera pocztowego | configKeys/ common.param.smtp_ignore_certificate_errors | Wartość domyślna: None Dopuszczalne wartości: None, All, RemoteCertificateNotAvailable,RemoteCertificateNameMismatch, RemoteCertificateChainErrors. Można połączyć kilka flag rozdzielając je przecinkiem. | |
| Nazwa użytkownika dla usługi SMTP | configKeys/ common.param.smtp_username | ||
| Hasło użytkownika dla usługi SMTP | configKeys/ common.param.smtp_password |
Informacje szczegółowe o dopuszczalnych wartościach parametrów znajdują się w dokumentacji technicznej w rozdziale: Konfiguracja SMTP - common.param.smtp_
W przypadku korzystania z logowania poprzez AD, włączenie SSO (Single Sign On)
W przypadku, gdy instalowana aplikacja końcowa korzysta z autoryzacji i autentykacji z AD należy skonfigurować w niej połączenie z providerem AciveDirectory.
Wymagane jest:
- Otworzenie ruchu z poziomu serwerów grupy Web i App do serwera ActiveDirectory.
Dane techniczne wymagane do podania podczas instalacji:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Parametry wspólne podczas połączenia z AD | Połączenie do serwera AD | configKeys/common.connection.provider_ad | LDAP://[ldap_server]:[port] np.: LDAP://server_address:389 LDAPS LDAP://server_address:636 Ciąg połączenia zawsze powinien zaczynać się dużymi literami: LDAP |
| Nazwa użytkownika jakim łączymy się z AD | configKeys/common.param.provider_ad_user | Puste wartości w polu użytkownik i hasło spowoduje połączenie się na użytkowniku, na którym działa aplikacja. | |
| Hasło użytkownika jakim łączymy się z AD | configKeys/common.param.provider_ad_password | Puste wartości w polu użytkownik i hasło spowoduje połączenie się na użytkowniku, na którym działa aplikacja. | |
| Autentykacja użytkowników | Nazwa providera logowania | configKeys/common.param.user_provider | W przypadku połączenia z AD należy podać wartość AD. Dopuszczalne wartości: AD, VIP, VIPService, FAKE. |
| Autoryzacja użytkowników | Nazwa providera ról | configKeys/common.param.role_provider | W przypadku połączenia z AD należy podać wartość AD. Dopuszczalne wartości: AD, VIP, VIPService, FAKE. |
| Definicja kontenera ról w AD, z którego będą pobierane role (zawężenie) | configKeys/common.param.provider_ad_role_container | Ścieżka kontenera AD, np. „OU=Grupy Zabezpieczeń, OU=Konta i grupy pomocnicze, DC=mydomain, DC=local” (hint: użyj AD Explorera). | |
| Definicja kontenera użytkowników w AD, z którego będą pobierani użytkownicy (zawężenie) | configKeys/common.param.provider_ad_user_container | Ścieżka kontenera AD, np. „CN=Users,DC=mydomain,DC=local” (hint: użyj AD Explorera). W przypadku pustej wartości wyszukiwanie obejmie całe AD |
Dodatkowo, jeśli chcemy włączyć logowanie SSO (Single Sign On) należy podać parametry:
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Parametry wspólne podczas połączenia z AD | Pokazywanie linka do logowania SSO na standardowej stronie logowania. | configKeys/www.param.windows_authentication | Aby pokazać link do logowania SSO należy podać wartość „true”. |
Tworząc projekt należy włączyć funkcjonalność SSO (Single Sign On) przez podanie parametru „-FeatureSSO On”.
Wykorzystanie logowania SSO w aplikacji wymaga również spełnienia dwóch warunków:
- Adres serwera, z którym się łączymy musi być traktowany jako adres lokalnego intranetu. Adres serwera można dodać do strefy Intranet za pomocą modyfikacji Opcji internetowych:
- lub można dodać je automatycznie na poziomie domeny – np. w sposób opisany na stronie https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-quick-start#why-you-need-to-modify-user-intranet-zone-settings
(Uwaga: adresy dodane w ten sposób respektowane są przez przeglądarki Edge i Chrome)
- Niezbędne jest także poprawne skonfigurowanie Service Principal Names na potrzeby SSO. Sposób konfiguracji SPN jest opisany np. tutaj: https://www.microsoft.com/en-us/dynamics-365/blog/it-professional/2009/08/06/configuring-service-principal-names/
W przypadku logowania poprzez usługę Active Directory Federation Services (AD FS)
Jeżeli aplikacja końcowa korzysta z uwierzytelniania usługi AD FS to należy:
- skonfigurować uwierzytelnienie i autoryzację poprzez wybrany provider (AD, VipService, etc.) oraz zadbać o to, by loginy użytkowników logujących się przez AD FS znajdowały się również w wybranym providerze,
- dodać aplikację do zaufanych dostawców w usłudze AD FS.
Mechanizm logowania przez AD FS działa następująco:
- Użytkownik loguje się w AD FS za pomocą loginu i hasła.
- W skonfigurowanym providerze użytkowników, na podstawie loginu użytkownika, znajdowany jest jego identyfikator (w przypadku nie znalezienia następuje automatyczne przekierowanie na stronę wylogowania AD FS).
- Odnaleziony identyfikator użytkownika wykorzystywany jest w skonfigurowanym providerze uprawnień do pobrania ról użytkownika.
Dane techniczne wymagane do podania podczas instalacji
| Zakres danych | Parametr | Nazwa parametru | Uwagi |
|---|---|---|---|
| Parametry wspólne podczas połączenia z usługą AD FS | Włączenie uwierzytelniania przez usługi AD FS | configKeys/common.param.adfs_authentication | Aby właczyć uwierzytelnienie przez usługi AD FS należy podać wartość „true” |
| Adres URL pliku xml z metadanymi usługi AD FS | configKeys/common.param.adfs_metadata | Adres https np. https://[serwerADFS]/FederationMetadata/2007-06/FederationMetadata.xml |
Uzyskanie adresu URL metadanych federacji xml
Adres względny pliku xml z metadanymi możemy uzyskać z okna zarządzania AD FS na serwerze wybierając kolejno AD FS ->Service ->Endpoints. URL powinien być widoczny w sekcji Metadata.
Dodanie aplikacji WEB do jednostki zaufanej
- W celu dodania aplikacji końcowej do jednostki zaufanej należy wybrać kolejno w oknie zarządzania AD FS na serwerze AD FS -> Trust Relationships -> Relying Party Trusts i w oknie akcji -> Add Relying Party Trust.
- W kreatorze dodawania zaufania dla jednostki zależnej klikamy start i wybieramy opcję ręcznego wprowadzenia danych o jednostce zależnej.
- W sekcji konfiguracji wyświetlanej nazwy wpisujemy nazwę identyfikującą jednostkę zależną.
- W sekcji wybór profilu wybieramy profil AD FS odpowiedni dla danego środowiska.
- W sekcji konfiguracji certyfikatu korzystamy z domyślnych ustawień.
- W sekcji konfiguracji adresu URL zaznaczamy pole Włącz obsługę protokołu WS-Federation Passive protocol (Enable support for the WS-Federation Passive Protocol) i wprowadzamy adres URL aplikacji końcowej zakończony ukośnikiem.
- W sekcji konfiguracji identyfikatorów korzystamy z domyślnych ustawień.
- W sekcji wyboru reguł autoryzacji wybieramy opcję Zezwalaj wszystkim użytkownikom na dostęp do tej jednostki zależnej (Permit all users to access this relying party).
- W sekcji przeglądania ustawień jednostki zależnej, upewniamy się, że konfiguracja jest prawidłowa.
- W sekcji końcowej zaznaczamy opcję automatycznego otwarcia okna dialogowego edycji poświadczeń reguł.
- W nowym oknie kreatora naciskamy przycisk dodaj regułę (Add rule).
- W etapie wyboru szablonu reguły wybieramy Wysyłaj atrybuty LDAP jako poświadczenia (Send LDAP Attributes as Claims).
- W sekcji konfiguracji reguły uzupełniamy nazwę reguły, wartość dla magazynu atrybutów oraz mapowania atrybutów LDAP na typy poświadczeń wychodzących zgodnie z poniższą tabelą.
Tabela zawiera mapowania, które wymagane są do uwierzytelnienia przez usługi AD FS.
| Atrybut LDAP | Typ poświadczenia wychodzącego | Uwagi |
|---|---|---|
| SAM-Account-Name | Name | Atrybut SAM-Account-Name to login użytkownika, na którego podstawie szukany będzie identyfikator w providerze użytkowników. |
| objectSid | Primary SID | Atrybut objectSid zawiera unikalny SID użytkownika, nazwa może różnić się w zależności od konfiguracji AD. |
W przypadku instalacji na klastrze FailOver
Skrypty instalacyjne VSoft archITekt umożliwiają instalację serwisów na klastrze FailOver. W celu instalacji na klastrze należy do skryptów instalacyjnych dostarczyć informację:
- Nazwa klastra
- Nazwa grupy (nazwa roli typu „Generic service” do której zostaną dodane usługi archITekta).
Skrypty instalacyjne w sposób automatyczny tworzą zasoby w podanej roli typu „Generic service” dla każdego instalowanego serwisu. W procesie odinstalowywania zasoby są usuwane z roli.
Instalując archITekta na klastrze FailOver, usługi aplikacji instalowane są w trybie manualnym. Ich uruchamianie/zatrzymywanie odbywa się za pomocą API klastra FailOver.
Strefa czasowa aplikacji
Aplikacja uruchomiona na VSoft archITekt może działać używając innej strefy czasowej niż skonfigurowana na serwerze. Oznacza to, że dla aplikacji czas systemowy będzie taki jak skonfigurowany, niezależnie od tego w jakiej strefie czasowej działa serwer aplikacyjny i serwer bazy danych.
Powyższa możliwość konfiguracji ma znaczenie, gdy uruchamiamy aplikację w skonteneryzowanym środowisku chmurowym VSoftCloud, w którym wszystkie serwery działają w oparciu o czas UTC, a na jednym serwerze jest uruchomionych wiele aplikacji, z których każda może pracować w różnej strefie czasowej.
Aby zmienić strefę czasową w której ma działać aplikacja należy dodać ustawienie konfiguracyjne (zmodyfikować Config Key)
common.param.systemtimezone
a jako wartość należy podać:
- strefę czasową zgodnie ze standardem IANA (https://nodatime.org/TimeZones ; https://www.iana.org/time-zones) np. "Europe/Warsaw".
- Lub tekst "Local" jeśli ma zostać użyta strefa czasowa zgodna ze strefą czasową serwera.
Brak podania tego wpisu spowoduje działanie jak w przypadku podania wartości "Local" – zostanie użyta strefa czasowa serwera.
Składowanie sesji w bazie danych
Domyślnie aplikacja przechowuje dane sesji użytkownika w pamięci. Oznacza to, że w przypadku restartu aplikacji WWW użytkownicy są wylogowywani z aplikacji. Istnieje możliwość zmiany tego zachowania.
Sesje użytkowników mogą być przechowywane w bazie danych, co będzie oznaczało, że nie będą wylogowywani w przypadku restartu aplikacji WWW.
Aby zmienić sposób przechowywania sesji należy dodać ustawienie konfiguracyjne (zmodyfikować Config Key)
www.param.session_mode
Zmienna przyjmuje wartości:
- przechowywanie sesji w pamięci (ustawienie domyślne): InProc
- przechowywanie sesji w bazie danych (baza DATA):
- gdy aplikacja działa na serwerze bazodanowym SQL Server: SQLServer
- gdy aplikacja działa na serwerze bazodanowym PostgreSQL: Custom