Usługi katalogowe - OpenLDAP (3) - Konfiguracja

W poprzednim wpisie dotyczącym usług katalogowych opisałem proces instalacji serwera OpenLDAP. Dzisiaj, zgodnie z zapowiedzą przedstawię sposób konfiguracji tej aplikacji oraz zaprezentuję to jak ona działa.


Konfiguracja
Proces konfiguracji sprowadza się do wprowadzeniu w pliku /usr/local/etc/openldap/slapd.conf odpowiednich wartości dla poszczególnych parametrów.

Jednym z parametrów, który należy określić jest hasło użytkownika zarządzającego serwerem, aby uniknąć wpisywania tego hasła w sposób czytelny można skorzystać z narzędzia slappasswd. Pozwala ono wygenerować zaszyfrowany ciąg hasła, który następnie można bezpiecznie umieścić w pliku konfiguracyjny. Wygeneruję zatem taki ciąg wydając polecenie i podając odpowiednie dane

• slappasswd

Wynik działania zaprezentowano powyżej.

Założyłem dodatkowo, że serwer będzie pracował w domenie: mbsoftware.com.pl, a administrator będzie nazywał się po prostu: admin.

Teraz możemy przystąpić do wprowadzania wartości w wymienionym wcześniej pliku. Przykładowy szablon pliku znajduje się poniżej:

database bdb

suffix "dc=,dc=<1-WSZY_CZŁON_DOMENY>" 

rootdn "cn=,dc=,dc=<1-WSZY_CZŁON_DOMENY>" 

rootpw

directory

Znając domenę, nazwę użytkownika oraz ciąg, który będzie reprezentował hasło pozostaje nam do określenia katalog - np. /usr/local/var/openldap-data - trzeba zadbać, aby przed uruchomieniem aplikacji został on utworzony.
Na podstawie powyższych danych wprowadzamy zmiany w pliku:

database bdb

suffix "dc=mbsoftware,dc=com,dc=pl" 

rootdn "cn=admin,dc=mbsoftware,dc=com,dc=pl" 

rootpw {SSHA}Uer3DSw297HyPvs25Z4u3tnyp2hrUB8i

directory /usr/local/var/openldap-data

Nie możemy zapomnieć o utworzeniu wyżej wymienionego katalogu. Poniżej fragment pliku slapd.conf oraz zmiany, które w nim wprowadziłem.

Uruchamianie
Aby uruchomić serwer OpenLDAP, należy wydać polecenie:

• sudo /usr/local/libexec/slapd

Weryfikacja działania
Sprawdźmy teraz czy serwer odpalił się poprawnie i czy odpowiada zgodnie z konfiguracją na zapytania, które można zlecić do wykonania za pomocą komendy ldapsearch. Wykonajmy poniższą komendę:

• ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

W wyniku działania powinniśmy dostać informację o sufiksie jaki został wprowadzony w pliku slapd.conf.
Poniższy zrzut ekranu prezentuje wynik, jaki uzyskałem dla mojej konfiguracji.

Podsumowanie
Konfiguracja oraz uruchamianie aplikacji nie wymaga włożenia wiele wysiłku, jednak aby zapewnić większe bezpieczeństwo całej aplikacji należy zapoznać się z następującą lekturą udostępnioną na stronie OpenLDAP.

Wydaje się, że cykl dotyczący usług katalogowych można już zamknąć. Temat ten opisywałem z ważnego powodu - planuję zintegrować OpenLDAP z innym systemem. Zanim postawię kropkę nad "i" w ostatnim "odcinku" wprowadzę do działającej instancji serwera usług katalogowych dane z których zamierzam skorzystać w przyszłości. 

Usługi katalogowe - OpenLDAP (2) - Instalacja

Poprzednim razem w wielkim skrócie opisałem przypadek wykorzystania systemów usług katalogowych. Dzisiaj chciałbym zaznajomić Was z systemem OpenLDAP.

Zanim zaczniemy, chciałbym przedstawić prostą strukturę organizacyjną wyimaginowanej firmy obsługującej internetowe wnioski o produkty finansowe dla dużego banku. Firma będzie się składać z dwóch pracowników: Kierownika oraz Pracownika. Kierownik będzie posiadał uprawnienia do dokonywania audytu, natomiast pracownik do przetwarzania wniosków.

Instalacja
Proces instalacji należy rozpocząć od ściągnięcia archiwum z aplikacją. Najlepiej skorzystać z dystrybucji przygotowanej przez autorów, która jest dostępna pod adresem: http://www.openldap.org/software/download/.
Po ściągnięciu paczki, należy ją wgrać na maszynę wirtualną - jak to można zrobić? Teoretycznie VirtualBox udostępnia mechanizm współdzielenia katalogów z systemem hostem (Windows XP w moim wypadku) jednak do tej pory nie udało mi się tego uruchomić. Aby wgrać paczkę do Ubuntu odpalonego na maszynie wirtualnej wykorzystajmy proste narzędzie WinSCP, które pracuje jako menadżer plików po szyfrowanym połączeniu SSH.
Kiedy uda się wgrać pakiet na maszynę należy go rozpakować poniższym poleceniem:

• gunzip -c openldap-VERSION.tgz | tar xvfB -

Ponieważ cały proces polega zbudowaniu aplikacji z kodów źródłowych może zaistnieć potrzeba zainstalowania kompilatorów:

• sudo apt-get install gcc

Dodatkowo do poprawnego działania całej aplikacji potrzebna jest baza danych BekeleyDB. Również ją można w łatwy sposób zainstalować wykorzystując apt-get lub aptitude:

• sudo aptitude install libdb4.7 libdb4.7-dev

Kolejnym krokiem jest konfiguracja etapu budowania - w tym celu w katalogu do którego rozpakowało się archiwum z OpenLDAP wykonujemy poniższe zapytanie:

• ./configure

Dokonuje ono sprawdzenia czy wszystkie wymagane narzędzia są dostępne w systemie (kompilator, baza danych itp.). Teoretycznie operacja powinna zakończyć się sukcesem, ponieważ zainstalowaliśmy wcześniej zarówno kompilator jak i wymaganą przez OpenLDAP bazę danych. Jeżeli pojawią się problemy - brak jakiejś aplikacji zależnej to należy poszukać ją za pomocą aptitude lub apt-get i zainstalować po czym ponowić wywołanie ./configure.

Przedostatnim etapem jest kompilacja całej aplikacji za pomocą dwóch poleceń:

• make depend
• make

Należy je wykonać kolejno po sobie. Ta druga może trochę trwać z racji tego, że wykonuje budowanie całej aplikacji z kodów źródłowych. Sukces kompilacji obwieści komunikat zaprezentowany na poniższym zrzucie ekranu:

Aby sprawdzić czy cały proces budowania przebiegł pomyślnie można odpalić testy, które zweryfikują całą aplikację:

• make test

Procedura ta jest jednak czasochłonna i ku mojemu rozczarowaniu okazało się, że nie wszystkie testy przeszły. Nie ma się jednak co załamywać - spróbujemy poradzić sobie z aplikacją pomimo tych niedogodności.

Ostatnim krokiem procesu instalacji jest "osadzenie" skompilowanej aplikacji w systemie:

• sudo make install

W rezultacie powinniśmy uzyskać działającą aplikację OpenLDAP w systemie. W następnym wpisie postaram się przybliżyć proces jej konfiguracji oraz zaprezentować działanie.

Usługi katalogowe - OpenLDAP (1)

Tak jak wspomniałem w poprzednim wpisie chciałbym krótko przedstawić usługi katalogowe. Do czego zatem one służą? Przede wszystkim w dużych firmach jako jeden punkt zawierający dane katalogowe (informacje o pracownikach, urządzeniach wykorzystywanych w pracy, strukturze organizacyjnej, itp.). 

Wyobraźcie sobie, że firma korzysta z wielu aplikacji, które pomagają realizować jej biznes. Każda z tych aplikacji musi wiedzieć o użytkownikach, którzy mogą wywoływać jej funkcjonalności oraz uprawnienia dla tych użytkowników. Dodatkowo w kilku z tych aplikacji określono, aby użytkownicy oraz inne jednostki logiczne odwzorowywały strukturę organizacyjną firmy. Jeżeli aplikacje te dostarczali różni wykonawcy to 100% można uznać, że każda z tych funkcjonalności została zrealizowana w inny sposób i w każdej istnieje osobny moduł administracyjny pozwalający zarządzać strukturą, uprawnieniami oraz użytkownikami. Prowadzi to niechybnie do wzrostu kosztów administrowania tymi aplikacjami w takiej firmie. Dlaczego ich nie obniżyć? 

Wszystkie funkcjonalności administracyjne są do siebie bardzo podobne - sprowadzają się do zarządzania katalogami: użytkowników, struktury firmy, uprawnień, sprzętu, itp. Czemu zatem nie może istnieć jeden system, który te dane będzie przechowywał w jednym miejscu i który będzie udostępniał je wszystkim zainteresowanym? Efekt jaki w ten sposób można osiągnąć to przede wszystkim obniżenie kosztów administracyjnych, które przy zarządzaniu wieloma aplikacjami mogą być całkiem spore. 

Realizację tych celów pomagają osiągnąć systemy usług katalogowych. Jednym z takich systemów jest  OpenLDAP - darmowa implementacja Lightweight Directory Access Protocol. W kilku najbliższych wpisach postaram się przybliżyć Wam instalację, konfigurację oraz użytkowanie tego systemu.

Anonimowość w sieci - Tor dla FireFox'a

W jednym z poprzednich postów opisywałem jak uruchomić program Freenet, który w dobie coraz bardziej zwiększającej się kontroli internetu umożliwia zachowanie pełnej anonimowości. Pewnym istotnym mankamentem tego rozwiązania jest użyteczność. Niestety, ale w porównaniu z nieanonimową stroną Internetu tej anonimowej brakuj dynamiczności. Strony, które w sieci Freenet można przeglądać są całkowicie statyczne. Drugim mankamentem jest sposób wyszukiwania oraz czas transmisji strony do przeglądarki. Niestety od wyszukiwania nie ma co oczekiwać szybkości ani skuteczności na miarę Google'a. Co więcej jeżeli podpięci będziemy do "złośliwego" węzła możemy zostać zalani fałszywymi treściami nieodpowiadającymi temu co w rzeczywistości wyszukujemy. To wszystko za jedną cenę całkowitej anonimowości.

Zastanówmy się czy nie istnieje jednak łatwiejszy sposób bycia anonimowym z jednoczesnym zachowaniem możliwości korzystania z dobrodziejstw ogólnodostępnego Internetu. Okazuje się, że jest taka możliwość wystarczy skorzystać z Tor'a. Jest to aplikacja, która poprzez łączenie się z serwerami proxy uruchamianymi na innych maszynach pozwala surfować po Internecie. Informacje pomiędzy przeglądarką a stroną internetową przechodzą przez kilka (kilkanaście) węzłów sieci i są na tej drodze w pełni szyfrowane (jedyne nieszyfrowane połączenie występuje między stroną internetową o ostatnim z węzłów). Żaden z węzłów nie przechowuje informacji o tym co, kiedy i do kogo przesłał. Żaden węzeł nie jest w stanie określić do kogo na prawdę jest adresowana przesyłka, wie tylko do którego węzła ma to wrócić, ale nie wie czy jest to ostateczny klient czy tylko węzeł pośredniczący.

Oczywiście, nie jest to skuteczna, 100% ochrona prywatności. Jeżeli aplikacja wraz z przeglądarką internetową będą wykorzystywane w sposób niepoprawny (np. działać będą wtyczki Flash czy inne, które mogą bezpośrednio uderzać do serwera) łatwo można zostać zidentyfikowanym. Teoretycznie możliwe jest również za pomocą analizy statystycznej określenie czy jeden z węzłów sąsiadujących temu, na którym się przeprowadza badania nie jest odbiorcą ostatecznych konkretnych, przesyłanych treści. Ryzyko takiego działania wprawdzie jest niewielkie, ale trzeba sobie zdawać sprawę z tego, że istnieje.

Kolejnym mankamentem jest prędkość działania. Z racji tego, że w tym rozwiązaniu również uczestniczą węzły pośredniczące (we Freenet również tak jest) przesyłanie pomiędzy nimi informacji zamiast bezpośredniego uderzenia do serwera trwa dłużej.

Poznaliśmy zatem jak działa Tor oraz jakie są jego wady i zalety. Sprawdźmy teraz jak zachowuje się on w praktyce. Należy ściągnąć plik instalacyjna Tor'a i rozpakować go na komputerze po ściągnięciu. Jest to paczka, która zawiera komplet Tor'a, aplikacji pomocniczych (np.: serwera Proxy) oraz FireFox'a z odpowiednio skonfigurowaną wtyczką. Teraz wystarczy tylko odpalić: Start Tor Browser.exe.

Po uruchomieniu aplikacji powinno pokazać się okno jak na powyższym rysunku. Kiedy uda się nawiązać połączenie z siecią Tor automatycznie uruchomiona zostanie przeglądarka FireFox załączona w ściągniętym pakiecie. Warto zwrócić uwagę, że nie zawiera ona żadnych wtyczek - pozwala to zapewnić, że nasza anonimowość nie zostanie zdradzona przez działanie jakiegoś nieodpowiedniego pluginu.

Pierwszą stroną prezentowaną po załadowaniu FireFoxa jest ta na której Tor udostępnia informacje pod jakim adresem jesteśmy obecnie widziani. Jeżeli przypatrzycie się bliżej to zauważycie, że widziany przez stronę internetową adres z którego "nawiązano" połączenie to: 208.53.142.40, a miejsce to znajduje się w przybliżeniu w USA:

Po jakimś czasie zmienia się nasz węzeł z którego "wychodzimy" na świat i mamy inny adres: 92.241.190.188.

A skąd teraz jesteśmy widoczni dla witryn internetowych?

Samą operację zmiany tożsamości możemy wymusić na Tor'ze przez wybranie opcji: Użyj nowej tożsamości. Od tej pory możemy prawie całkowicie anonimowo korzystać z dobrodziejstw Internetu.

Mam nadzieję, że ten krótki cykl artykułów przybliżył Wam więcej informacji o tym jak zachować anonimowość w sieci w dobie powszechnej inwigilacji na ulicach, w pracy i w Internecie. Przynajmniej tam będziemy mogli zachować swoją prawdziwą tożsamość w tajemnicy.

O powrocie - krótkie podsumowanie dotychczasowego blogowania i plany na przyszłość

Po dłuższej przerwie postanowiłem wznowić pisanie bloga. Zanim jednak przejdę do konkretów chciałbym podsumować to co do tej pory zrobiłem ze szczególnym naciskiem na to co rozpocząłem a jeszcze nie zakończyłem. Trochę się takich tematów zebrało.

Po pierwsze rozpocząłem temat związany z DLNA: Projekt DLNA. Jego celem był przegląd software'owych rozwiązań systemów tej  klasy. Projekt skończył się na etapie wybrania programów do porównania oraz przygotowania szablonu systemu linux'owego stanowiącego podstawę do instalowania oraz testowania oprogramowania. Ze względu na chęć wykorzystania tego rozwiązania w domu temat zamierzam aktualizować.

W międzyczasie z potrzeby powstania i utrzymania szablonu wirtualnego systemu linux'owego stanowiącego bazę do testowania innych rozwiązań pisałem o wirtualizacji . Kolejne wpisy dotyczyły instalacji i konfiguracja środowiska VirtualBox, instalacji dystrybucji Ubuntu oraz klonowania maszyn. 

Na fali popularności Google Wave powstały artykuły (Instalacja serwera XMPP, Konfiguracja serwera XMPP, Sprawdzamy działanie XMPP, Instalacja wtyczki Wave)   opisujące instalację własnego serwera Wave. Pokładałem w nim nadzieję wykorzystania tego rozwiązania w firmie w której pracuję. Niestety problemem okazał się brak klientów dorównujących pierwowzorowi Google'a. Być może kiedy powstanie odpowiedni program zaproponuję wdrożenie tego rozwiązania w pracy. 

Ostatni cykl artykułów dotyczył przykładu wdrożenia SOA - Integracja systemów bankowych. Nie został on ukończony jednak nie zamierzam z niego zrezygnować, ponieważ wydaje mi się on bardzo pouczający i niezwykle rozwijający. Poza tym, oprócz przyjemności intelektualnej, którą realizacja tego projektu ma mi przynieść zakładam, że w przyszłości przyniesie mi ona również wymierne korzyści finansowe, ale o tym chwilowo nie chcę wspominać.

Zanim jednak powrócę do kontynuowania wyżej wymienionych tematów (Integracji oraz projektu DLNA) chciałbym zaznajomić się z usługami katalogowymi i podzielić z Wami moimi spostrzeżeniami na ten temat. Rozpocznę nowy cykl dotyczący tego tematu. W zamierzeniu ma on wpasować się w rozwiązanie Integracji systemów bankowych, a w przyszłości wiedza zdobyta dzięki niemu zostać wykorzystana w kolejnych projektach.

Zachęcam zatem do odwiedzania bloga.

SOA w akcji - integracja systemów bankowych (c.d. 4)

Najwyższy czas na przygotowanie aplikacji, która umożliwi klientom składanie wniosków o produkty bankowe. Zanim powstanie program należy zdefiniować kontrakt pomiędzy nim, a systemem procesującym wnioski na szynie usług. Komunikacja odbywać się będzie za pomocą usługi WebService. Należy zatem przygotować definicję tej usługi - plik WSDL oraz powiązany z nim model zapisany w pliku XSD. Zatem do dzieła.

Zastanówmy się nad tym jakie dane potrzebujemy zebrać od klienta, w celu poprawnego przeprocesowania wniosku. Na pewno potrzebne są dane osobiste: imię, nazwisko, numer Pesel, seria oraz numer dowodu osobistego lub paszportu. Dodatkowo potrzebujemy dane adresowe klienta. Ostatnią i najważniejszą rzeczą jest wybór produktów - rachunku i karty.

Podsumowując aplikacja wnioskowa prosi klienta o podanie następujących danych:

• Imię
• Nazwisko
• Numer Pesel
• Seria i numer dowodu osobistego
• Seria i numer paszportu
• Ulica z numerem domu i mieszkania adresu zameldowania
• Miasto
• Kod pocztowy
• Rodzaj konta - waluta rachunku
• Typ karty

Na podstawie tych wymagań utworzono dokument XSD. Znaleźć go można pod następującym adresem projektu BankSourceSystem.

Potrzebujemy zdefiniować dodatkowo sytuacje wyjątkowe ich opis, w postacie XSD, również udostępniłem w projekcie BankSourceSystem (dokładny link do pliku).

Ostatnim zadaniem jest utworzenie samego pliku WSDL. Interfejs samej usługi jest prosty: jako parametr przyjmuje dane wypełnione przez klienta i zwraca identyfikator uruchomionej sprawy. W razie niepowodzenia zwraca wyjątek wyżej wymieniony. WSDL dostępny jest pod następującym linkiem.

Z tak przygotowanym opisem usługi jesteśmy gotowi do napisanie aplikacji zbierającej wnioski. Opis tego komponentu przedstawię jednak następnym razem.

SOA w akcji - integracja systemów bankowych (c.d. 3)

Obiecałem ostatnio, że przedstawię aplikację, której zadaniem będzie zbieranie od klientów wniosków o konto osobiste z opcjonalną kartą. Postanowiłem jednak, że w pierwszej kolejności powinniśmy bliżej poznać architekturę technologiczną całego projektu. Dlatego dzisiaj postaram się przybliżyć serce całego rozwiązania, czyli OpenESB - platformę integracyjną.

Głównym celem postawionym przed OpenESB jest uproszczenie integracji komponentów korzystających z różnych technologii. U podstaw architektury tego rozwiązania leży implementacja specyfikacji JBI. Standard ten dzieli wszystkie komponenty na dwa rodzaje: komponenty połączeniowe (BC) oraz silniki usług (SE). Natomiast komunikacja między komponentami odbywa się za pomocą mechanizmu NMR (znormalizowany ruter wiadomości). Całość wygląda w następujący sposób (diagram zaczerpnięty ze strony JBI Component Technical Overview):

JBI Messaging Infrastructure (NMR) spina wszystkie komponenty, Service Engine (SE) oferują usługi wewnątrz kontenera, natomiast Binding Component oferują łączność z systemami zewnętrznymi.

Jakie usługi mogą oferować SE? W przypadku OpenESB jest to np.: BPEL SE oferujący możliwość instrumentacji procesów biznesowych; JavaEE SE, który zapewnia dostępność wszystkich komponentów JavaEE jako usługi JBI; XSLT SE oferujące transformacje XML czy WLM SE zapewniający zarządzanie zadaniami wymagającymi interakcji z człowiekiem.

Co oferują komponenty BC? Komunikację z zewnętrznymi usługami FTP (FTP BC), SMTP (SMTP BC), JMS (JMS BC), systemami plików (File BC), usługami REST (REST BC) i wiele innych.

Należy wziąć pod uwagę, że dołożenie kolejnych komponentów SE jak i BC nie stanowi problemu i ciągle rozwijane są nowe elementy systemu. Na następującej stronie można znaleźć listę wszystkich obsługiwanych przez OpenESB komponentów

Skoro posiadamy już ogólną wiedzę o OpenESB sprawdźmy czego będziemy potrzebować przy realizacji postawionych w pierwszym poście serii wymagań.

Aplikacja BankSourceSystem(BSS) symulująca systemy bankowe została wykonana w całości w technologii JEE. Z racji tego, że OpenESB posiada komponent JavaEE SE, można wyżej wymienioną aplikację zdeployować i korzystać z jej funkcjonalności wewnątrz kontenera JBI. Jest to pierwsze rozwiązanie, które nasuwa się po zapoznaniu się z architekturą szyny. Jednak początkowo zamierzałem wykorzystać funkcjonalności BSS w zupełnie inny sposób. Aplikacja BSS miała być odseparowana od OpenESB - znajdować się na zupełnie innym serwerze aplikacji, a komunikacja z szyną miała odbywać się za pomocą usług WS wystawionych przez BSS. Ponieważ pojawiły się dwa rozwiązania spróbuję wdrożyć, a właściwie wypróbować oba. W pierwszym przypadku wykorzystam komponent JavaEE SE do komunikacji z aplikacją zdeployowaną razem z JBI, natomiast w drugim przypadku skorzystam z HTTP BC do komunikacji z odpowiednimi usługami wystawionymi przez BSS. 

Komponent HTTP BC zostanie wykorzystany również do odbierania informacji od aplikacji wnioskowej.

Centralnym punktem, gdzie znajdować się będzie logika biznesowa jest komponent BPEL SE. Usługa, która zostanie wystawiona w tym kontenerze będzie definiowała cały proces biznesowy realizacji zgłoszonego wniosku. Przepływ zdefiniowany w BPEL SE powiąże wszystkie pozostałe usługi w innych komponentach w całość.

W cały procesie zdefiniujemy jeden element styku, który wymagać będzie interakcji z użytkownikiem. Za realizację tego punktu odpowiadać będzie komponent WLM SE.

Podsumowując komponenty JBI, których wykorzystanie planujemy w ramach realizacji projektu: BPEL SE, JavaEE SE, WLM SE i HTTP BC.

Poniżej diagram prezentujący architekturę komponentów w pierwszym przypadku - wykorzystanie komponentu JavaEE SE:

Oraz drugi diagram prezentujący architekturę komponentów drugiego przypadku - dodatkowe wykorzystanie komponentu HTTP BC:

To by było na tyle jeżeli chodzi o opis wykorzystania szyny OpenESB i poszczególnych komponentów JBI. Co czeka nas w najbliższej przyszłości? Po pierwsze przygotowanie WSDLa za pomocą którego składane będą wnioski z aplikacji wnioskowej. Po drugie utworzenie samej aplikacji wnioskowej. Na samym końcu przygotowanie obsługi całego procesu wewnątrz kontenera JBI.

SOA w akcji - integracja systemów bankowych (c.d. 2)

W poprzednich "odcinkach" opisałem na czym polega i jaki ma cel nowy projekt, którego realizacji się podjąłem oraz zaprezentował efekt końcowy pierwszego etapu - aplikację BankSourceSystem. Dzisiaj chciałby powrócić do aplikacji i opisać jakie interfejsy symulowanych systemów wystawia ona za pomocą usług WebService.

Na poniższym rysunku przedstawiłem wszystkie interfejsy, które niezbędne są do realizacji postawionego celu biznesowego - automatyzacji procesu zakładania produktów bankowych.

Serwis udostępniany przez system MigDZ służy do sprawdzenia czy podany numer dokumentu (paszport lub dowód osobisty) nie został zastrzeżony. Usługa verifyDocument zwraca true jeżeli dokument znajdzie się w bazie dokumentów zastrzeżonych.

System Sanctions udostępnia usługę sprawdzając czy osoba o podanym imieniu i nazwisku nie znajduje się na liście osób objętych sankcjami. Usługa verifyEntity zwraca wartość true jeżeli imię i nazwisko zostaną dopasowane do jednego z rekordów bazy danych.

System Customers przechowujący informacje o klientach udostępnia 3 usługi pozwalające: zapisać nowego klienta w systemie (createCustomer); wyszukać klientów na podstawie peselu, dowodu osobistego lub numeru paszportu(findCustomers); oraz pobrać informacje o pojedynczy kliencie (getCustomer).

Ostatni system, Products, umożliwia założenie konta (createAccount) oraz karty (createCard) jak również pobranie informacji o konkretnych produktach (getAccount i getCard).

Kolejny etap obejmuje przygotowanie aplikacji wnioskowej, która posłuży zebraniu informacji od wnioskodawcy o produktach, które on zamawia. Opis programu przedstawię w jednym z kolejnych wpisów.

SOA w akcji - integracja systemów bankowych c.d.

Udało się zakończyć pierwszy etap projektu o którym wspominałem w jednym z poprzednich wpisów - przygotować aplikację, która symuluje zachowanie bankowych systemów źródłowych - BankSourceSystem.

Z technologicznego punktu widzenia aplikacja została wykonana z wykorzystaniem: JSF 2.0 oraz EJB 3.1. Zarówno rozwój jak i testy zostały przeprowadzone na serwerze aplikacji - Glassfish v3. Kody źródłowe dostępne są na SVN'owym repozytorium Google'a.

Tak jak wspomniałem poprzednio głównym zadaniem tego programu będzie symulowanie wielu systemów, z których może składać się system informatyczny banku. Symulacja ta ma na celu zademonstrowanie w jaki sposób może przebiegać integracja tych systemów w prostym procesie zamawiania produktów bankowych.

Symulacja jakich systemów wchodzi w grę?

• MigDZ - system, który umożliwia dostęp do informacjach o zastrzeżonych dokumentach: paszportach oraz dowodach osobistych.
• Sanctioned Entities - system przechowujący informacje o osobach znajdujących się na listach sankcyjnych np.: terrorystach, osobach zaangażowanych politycznie itp.
• Customers - prosty system przechowujący podstawowe informacje o klientach banku
• Products - system przechowujący informacje o produktach, które posiadają kliencie banku.

Interfejs aplikacji jest bardzo prosty i składa się z kilku stron, które udostępniają funkcjonalności poszczególnych systemów. Strona główna zawiera odnośniki do stron z poszczególnymi systemami.

Każdy z systemów składa się z dwóch elementów: listy prezentującej zgromadzone w systemie dane oraz formularza umożliwiającego wprowadzanie nowych danych lub modyfikacje istniejących.

MigDZ System

Lista danych:

Edycja danych:

Santioned Entities System

Lista danych:

Edycja danych:

Customers System

Lista danych:

Edycja danych:

Products System - Rachunki

Lista danych:

Edycja danych:

Products System - Karty

Lista danych:

Edycja danych:

Jednak nie to stanowi sedno tej aplikacji. Najważniejszą rzeczą są funkcjonalności udostępnione za pomocą usług WebService. Każdy system udostępnia jedną lub kilka funkcji, których wykorzystanie potrzebne jest do realizacji procesu biznesowego zamawiania produktów bankowych. Opis tych funkcji zamieszczę w następnym wpisie.

HSQLDB w Glassfish v3

Glassfish, jak każdy serwer aplikacji (SA), pozwala definiować pulę połączeń bazodanowych. Na potrzeby jednego z małych projektów próbowałem zaprzęgnąć testową bazę danych, która przechowywałaby informacji wyłącznie w pamięci w czasie działania instancji SA. Jest to bardzo wygodne podczas prowadzenia rozwoju aplikacji, ponieważ nie trzeba zajmować się konfiguracją bazy danych i dbaniem o jej "czystość" po kolejnych przyrostach funkcjonalności. Idealnie do tego zadania nadaje się HSQLDB z trybem "mem". W trybie pamięciowy tworzona jest struktura bazy, a dane zapamiętywane tylko przez okres uruchomienia bazy w maszynie wirtualnej. Kiedy maszyna jest wyłączana automatycznie wszystkie dane są tracone. Jak wspomniałem wcześniej takie działanie ma swoje plusy tylko w określonych sytuacjach. 

Jak skonfigurować połączenia w Glassfish, aby wykorzystywały HSQLDB w trybie "mem"? Pierwszym krokiem jest zaopatrzenie się w jar'a bazą HSQLDB. Na pewno można ją znaleźć na stronach jej twórców. Ściągniętego jar'a należy wgrać do odpowiedniego katalogu w utworzonej domenie Glassfish'a. Według dokumentacji mogą to być katalogi: /lib lub /lib/ext. Po dograniu biblioteki startujemy domenę i przechodzimy do konsoli administracyjnej (np. http://localhost:4848). Następnie w zakładce Resources->JDBC->Connection Pools tworzymy nową pulę połączeń (przycisk New). Nowemu połączeniu nadajemy nazwę i wskazujemy jego typ jako javax.sql.DataSource.

 

Zatwierdzamy zmiany przyciskiem Next. W kolejnym oknie podajemy nazwę klasy implementującej interfejs DataSource dostarczonej przez HSQLDB: org.hsqldb.jdbc.jdbcDataSource. W tym miejscu należy się drobna uwaga odnośnie wersji bazy danych. Zauważyłem, że podany wyżej interfejs od wersji 2.0 nazywa się org.hsqldb.jdbc.JDBCDataSource. Proszę zwrócić uwagę jaką wartość się tutaj podaje. Jeżeli podczas testowania połączenia wyskoczy błąd informujący o tym, że nie można odnaleźć klasy należy zwrócić uwagę na podanie poprawnej nazwy klasy implementującej DataSource.

Ostatnim etapem jest podanie dodatkowych parametrów połączenia bez których nie uda się uruchomić instancji HSQLDB. Poniżej lista parametrów oraz ich wartości:

1. User=sa
2. Password=()
3. driverClass=org.hsqldb.jdbcDriver
4. database=jdbc:hsqldb:mem:testname

Należy w tym miejscu zwrócić uwagę, że dzięki tym parametrom konfiguruje się bazę danych do pracy w trybie pamięciowym (parametr database)

Wprowadzone dane potwierdzamy przyciskiem Finish. Po przejściu w szczegóły nowo  utworzonej puli wykonać należy test poprawności połączenia - przycisk Ping.

Często popełnianym błędem jest niewrzucenie biblioteki do odpowiedniego katalogu w domenie glassfish, przez co sygnalizowany jest błąd o braku możliwości odnalezienie klasy implementującej interfejs DataSource. Zwrócić należy również uwagę na dodatkowe parametry za pomocą których można skonfigurować pulę.

Skoro udało się skonfigurować pulę połączeń to można wrócić do pisania funkcjonalności wykorzystujących DataSource oparte o te pule ;-)

SOA w akcji - integracji systemów bankowych

Powoli moje zainteresowania technologiami Javowymi zaczynają brać górę na blogu. Tym razem chciałbym zaproponować Wam projekt, którego celem będzie zapoznanie się z praktycznym wykorzystaniem SOA oraz technologiami z nim powiązanymi. Całość podzielona będzie na kilka etapów, a końcowym efektem będzie zintegrowana aplikacja do składania wniosków o produkty bankowe.

Integracja jakich systemów może wchodzić w grę w przypadku prostego wnioskowania o konto osobiste z kartą debetową? Po pierwsze należy sprawdzić czy wnioskodawca nie posługuje się zastrzeżonym dokumentem w systemie MigDZ. Po drugie należy sprawdzić czy wniosku nie składa osoba znajdująca się na listach terrorystycznych czy listach osób objętych sankcjami. W kolejnym etapie weryfikacji sprawdzamy czy wnioskodawca nie jest już klientem banku w systemie przechowującym informacje o klientach. Na koniec pozostaje założenie konta i karty w systemie przechowującym informacje o produktach klientów.

Oczywiście powyższy opis jest sporym uproszczeniem. Każdy bank ma zazwyczaj system dostępu elektronicznego, który może oferować jako dodatkowy produkt. Może również posiadać system maklerski, gdzie klienci składają zlecenia kupna i sprzedaży akcji lub jednostek funduszy inwestycyjnych. Nie wspominając już o systemach ubezpieczeniowych za pomocą których można oferować produkty ubezpieczeniowe.

Na potrzeby tego projektu przygotowana zostanie aplikacja symulująca kilku systemów źródłowych - BankSourceSystem. Symulować będzie ona funkcjonalności: sprawdzania klienta w MigDZ, sprawdzania czy nie znajduje się on na liście osób objętych sankcjami (terroryści na przykład), sprawdzania i zapisywania wnioskodawcy w systemie zarządzania klientami, zapisywać informacje o wnioskowanych produktach.

Kolejnym etapem będzie przygotowanie aplikacji, której celem jest zebranie informacji od klienta o produktach o które wnioskuje. Prostota tego typu aplikacji polega na tym, że prezentowanych jest kilka formularzy zbierających dane, które po zatwierdzeniu wniosku przekazywane są do aplikacji przetwarzającej go.


Ostatnim etapem jest przygotowanie aplikacji procesującej wniosek. Rozwiązań może być wiele - można skorzystać z systemu klasy workflow, który zapewni przepływ i realizację zadań w poszczególnych systemach źródłowcy; można również skorzystać z połączenia JBI oraz zintegrowanego silnika WS-BPEL, za pomocą którego również zrealizuje się opisane wcześniej wymagania.

Założeniem projektu co do ostatniego etapu jest skorzystanie z OpenESB. Jest to platforma, której głównym celem jest uproszczenie integracji biznesowej oraz ułatwienie implementacji architektury SOA. Udostępnia ona również komponenty JBI z których podczas wykonywania integracji zamierzam skorzystać.

W najbliższym czasie postaram się przedstawić opis prac nad pierwszym etapem projektu - przygotowaniem aplikacji symulującej systemy bankowe.

Wzorce JEE według Adama Bien'a

Zawodowo zajmuję się programowanie w Javie. Hobbystycznie, natomiast próbuję sił z JEE. Dlatego nie mogłem przejść obojętnie wobec książki, którą zaserwował Adam Bien - "Real World Java EE Patterns - Rethinking Best Practices". Dodatkowo w dotychczasowej karierze zawodowej zajmowałem się wyłącznie aplikacjami J2EE (ku mojemu wielkiemu rozczarowaniu). Jednak coraz więcej firm, dla których tworzone jest oprogramowanie migruje na serwery aplikacji zgodne ze specyfikacją JEE. Z tego powodu kwestią czasu jest kiedy w nowych projektach będzie można skorzystać z jej dobrodziejstw. Nie chcąc pozostać w tyle sięgnąłem po wyżej wymienioną książkę. 

 

Motywem przewodnim są wszechobecne wzorce. Adam skupia się w niej głównie na tych, które mogą być bardzo pomocne w tworzeniu aplikacji JEE. Pisze z perspektywy osoby, która wcześniej dokładnie poznała architekturę J2EE i rozlegle stosowała wzorce zaproponowane przez Sun'a. Wskazuje te które nie mają obecnie żadnego zastosowania w nowej architekturze, ponieważ nowe rozwiązania wyeliminowały potrzebę ich wykorzystania. Ukazuje również te, których znaczenie się nie zmieniło, jednak z przyczyn częstego i błędnego ich stosowania stara się wyraźnie zaznaczyć jak powinno się z nich korzystać.

 

Główny podział wzorców przebieg według wykorzystania  ich w odpowiednich warstwach. Warstwa integracji zawiera następujące wzorce: Service Facade, Service, Persistent Domain Object, Gateway, Fluid Logic, Paginator, Fase Lane Reader. Warstwa integracji natomiast: Data Access Object, Transfer Object., Service Activator. Dodatkowo w warstwie integracji opisuje strategie migracji beanów 2.x do 3.x ielegancki sposób wykorzystania Java Connector Architecture. 

Oprócz wymienionych wyżej wzorców przyporządkowanych do odpowiednich warstw przedstawione są inne, równie użyteczne jak: Service Starter, Singleton, Bean Locator, Thread Tracker, Dependency Injection Extender, Payload Extractor, Resource Binder i Context Holder.

Książkę czyta się bardzo przyjemnie. Każdy wzorzec zaprezentowany jest z punktu widzenia problemu, który rozwiązuje, strategii, testowania, dokumentowania, konsekwencji które niesie wykorzystanie i wskazania powiązanych wzorców. 

 

Moim zdaniem jest to obowiązkowa lektura dla architektów rozwiązań klasy Enterprise, jak również dla zwykłych programistów, którym przyjdzie implementować konkretne problemy biznesowe.

Prywatny serwer Wave - instalacja wtyczki Wave

Nasze kilkudniowe walki z własnym serwerem Wave zakończyliśmy na instalacji, konfiguracji oraz przetestowaniu serwera OpenFire. Kolejnym wielkim krokiem na drodze do sukcesu jest zainstalowanie samego rozszerzenia Fali i spięcie go z OpenFire.

Całą operację zaczynamy od ściągnięcia źródeł rozszerzenia za pomocą komendy: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Niespodziewanie w tym miejscu pojawił się pierwszy problem - co to za polecenie hg. Z pomocą przyszła konsola podpowiadając, że najpierw trzeba zdobyć samo narzędzie i można to zrobić wykonując następujące polecenie: sudo apt-get install mercurial. Po zainstalowaniu narzędzia wracamy ponownie do ściągnięcia kodów poleceniem: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Ściągnąwszy pomyślnie źródła przechodzimy do jednego z utworzonych katalogów: cd wave-protocol i wywołujemy budowę wtyczki poleceniem: ant. W tym miejscu ponownie zostajemy rozczarowani, ponieważ nie ma takiego polecenia. Na szczęście Ubuntu ponownie przychodzi nam z pomocą i proponuje ściągnięcie odpowiedniej aplikacji: sudo apt-get install ant. Gdy ją zainstalujemy ponownie próbujemy zbudować wtyczkę poleceniem: ant. Po jakimś czasie powinniśmy zostać poinformowani o sukcesie.

Kolejnym krokiem jest wygenerowanie odpowiednich certyfikatów bez których nie uda się uruchomić wtyczki. Mamy dwie opcje, albo wygenerujemy prosty certyfikat, albo certyfikat sygnowany przez centrum certyfikacji. Oczywiście w obu przypadkach posługujemy się znacznym uproszeniem, ale w momencie, gdy zechcemy oferować publiczny dostęp do serwera ważnym elementem może być uzyskanie prawdziwego certyfikatu poświadczonego przez zewnętrzną instytucję. Dla naszych testowych zastosować wystarczy pierwsza opcja. Poniżej znajduje się skrypt, który pozwoli nam wygenerować prosty certyfikat:

#!/bin/bash                                                                       

NAME=$1

if [ "$NAME" == '' ]
then
  echo "$0 " 1>&2
  exit 1
fi
openssl genrsa 1024 | openssl pkcs8 -topk8 -nocrypt -out $NAME.key
openssl req -new -x509 -nodes -sha1 -days 365 -key $NAME.key -out $NAME.crt

Wykonując ten skrypt zostaniemy poproszeni o podanie kilku danych dotyczących miejsca, firmy, nazwy oraz adresu email. W wyniku działania skryptu powinny zostać utworzone dwa pliki: $nazwa.key i $nazwa.crt, gdzie $nazwa to identyfikator podany podczas wywoływania skryptu. Na poniższym rysunku zaznaczyłem wywołanie generowania certyfikatu oraz utworzone pliki.

Zasada posługiwania się certyfikatem polega na tym, że plik z rozszerzeniem *.crt udostępniamy publicznie osobom, które będą mogły potwierdzić otwartą przez nas komunikację (np. maile) oraz zaszyfrować przeznaczoną tylko do nas komunikację. Plik *.key jest natomiast przeznaczonym tylko dla nas kluczem prywatnym - nie można go nikomu przekazywać.


Będąc w posiadaniu obu plików możemy powrócić do konfiguracji pluginu. Po zbudowaniu aplikacji w katalogu wave-protocol dostępny jest plik: run-config.sh.example - jego zawartość należy skopiować do pliku: run-config.sh. Następnie należy dokonać zmian w nowoskopiowanym pliku.

Na powyższym rysunku zaznaczyłem miejsca w których dokonałem zmiany. W pierwszym przypadku zakomentowałem linijkę (znakiem: #). Druga zmiana polegała na podaniu nazwy lub adresu IP serwera - w naszym wypadku adres IP: 192.168.1.51. Kolejna zmiana dotyczy wprowadzenie sekretnego hasła, które podaliśmy podczas konfiguracji OpenFire. Dwie kolejne zmiany polegają na podaniu ścieżek do plików kolejno z kluczem (zmienna PRIVATE_KEY_FILENAME) i certyfikatem (zmienna CERTIFICATE_FILENAME_LIST) wcześniej wygenerowanymi (*.key i *.cert). Następne dwie zmiany polegają na podaniu adresu IP serwera w dwóch parametrach: CERTIFICATE_DOMAIN_NAME oraz XMPP_SERVER_PING. Ostatnia zmiana polegała na podaniu false w elemencie: WAVESERVER_DISABLE_SIGNER_VERIFICATION. 

Sprawdźmy czy poprawnie skonfigurowaliśmy certyfikaty za pomocą polecenia: ./check-certificates.sh. Jeżeli zobaczymy komunikat jak na poniższym obrazku to oznacza, że wszystko jest ok w tym punkcie.

Pozostaje uruchomić samego Wave'a za pomocą polecenia: ./run-server.sh.
Wraz z referencyjną implementacją protokołu dostarczony jest prosty klient konsolowy. Można go uruchomić za pomocą komendy: /run-client-console.sh . Po wydaniu tego polecenia pojawi się konsolowe okienko podzielone na dwie części. W jednej części prezentowany jest podgląd fal, natomiast w drugiej szczegóły tej jednej wybranej.


W celach testowych na dwóch różnych konsolach zalogowałem się jako dwaj różni użytkownicy i spróbowałem nawiązać komunikację. Efekt widać poniżej.

 

Ponieważ klient jest konsolowy wszystkie akcje należy wydawać za pomocą komend. Poniżej kilka poleceń:

1. /new - zakłada nową falę
2. /open - otwiera w prawym oknie podgląd fali o podanym identyfikatorze
3. /add @ - dodaje użytkownika do aktywnej fali
4. /remove @ - usuwa użytkownika z aktywnej fali

Więcej poleceń znaleźć można na następującej stronie.


W ten sposób dobrnęliśmy do końca. Udało się nam uruchomić i przetestować działanie naszego serwera Wave'a. Niestety osobiście odczuwam pewien niedosyt, jak się okazało w tej chwili jedynym znanym i darmowym klientem do otwartych fal jest klient konsolowy dostarczany wraz z referencyjną implementacją serwera. Oczywiście w przyszłości pewnie pojawią się nowe aplikacje, które będą wypełniać tę lukę jednak jak patrzę na webowego klienta Googlowskiego Wave to zaczynam wątpić czy kiedykolwiek będą one w stanie dorównać pierwowzorowi.

Prywatny serwer Wave - sprawdzamy działanie XMPP

Jak napisałem w jednym z poprzednich postów dotyczących Wave - rozwiązanie, które zaserwował Google oparte jest o protokół komunikacyjny XMPP. Sam "core" Fali to rozszerzenie tego protokołu.

W poprzednim wpisie opisałem jak skonfigurować serwer XMPP - OpenFire. Z racji, że nie jest to nic innego jak tylko serwer komunikacyjny, spróbujemy połączyć się z nim wykorzystując ogólnie znane aplikacje klienckie. Chciałbym w tym miejscu zwrócić uwagę, że cała konfiguracja, którą wykonaliśmy do tej pory nie dotyczyła Wave samego w sobie, a jedynie wymienionego wyżej serwera komunikacyjnego.

Zanim wybierzemy aplikację kliencką utwórzmy dwa konta użytkowników, które będą odpowiadały za komunikację w obrębie naszego serwera. W tym celu logujemy się na konto administracyjne konsoli serwera. A następnie przechodzimy na zakładkę: Użytkownicy/Grupy i z lewego menu wybieramy opcję: Utwórz nowego użytkownika. Podajemy jego identyfikator oraz hasło i zatwierdzamy dane przyciskiem Utwórz użytkownika.

Poniżej lista z aktualnymi użytkownikami systemu.

Z następującej strony pobieramy klienta Jabbera - PSI. Następnie instalujemy go i przeprowadzamy prostą konfigurację. Zaraz po zainstalowaniu aplikacji napotykamy pierwsze pytanie.

Szczerze mówiąc nie wiem co tu wybrać. Skoro samo konto utworzyliśmy wcześniej z poziomu konsoli administracyjnej to logiczne wydaje się, że trzeba wybrać opcję: Wykorzystaj istniejące konto. Po zatwierdzeniu pojawia się okienko z prośbą o uzupełnienie danych - wpisujemy więc nazwę użytkownika, którego wcześniej utworzyliśmy oraz jego hasło. Ponieważ użytkownicy związani są z serwerami, a sam protokół XMPP umożliwia komunikację pomiędzy serwerami unikalność nazwy użytkownika tworzy para nazwa usera i adres serwera. Dlatego w moim wypadku podałem ciąg: firstuser@192.168.1.51.

Sprawdźmy czy to co wprowadziliśmy wystarczy do połączenia się z serwerem - wybierzmy Zachowaj. Następnie w głównym okienku PSI zmieńmy status na Dostępny. Pojawi się informacja z prośbą o zatwierdzenie testu wiarygodności - wybieramy: Dodaj ten certyfikat do zaufanych.

No i... udało się zalogować.

Uzupełniamy dane o użytkowniku i klikamy Wyślij.

Spróbujmy teraz wykonać taką samą instalację na drugim komputerze - sprawdzimy w ten sposób jak działa komunikacja w obrębie zainstalowanego na maszynie wirtualnej serwera XMPP.

Próba dodania użytkownika firstuser do kontaktów seconduser zakończyła się pojawieniem poniższego komunikatu, który zatwierdzamy wybierając: Dodaj.

Efekt końcowy jest następujący: obaj użytkownicy widzą siebie wzajemnie i obaj mogą ze sobą rozmawiać.

Sprawdziliśmy jak działa nasz serwer i jak widać sprawuje się całkiem dobrze.

Zapraszam wszystkich do kolejnego wpisu z serii Wave. Tym razem zagłębimy się w tajniki instalacji i konfiguracji wtyczki Google'a.

Prywatny serwer Wave - konfiguracja serwera XMPP (OpenFire)

Ostatnim razem udało się utworzyć wirtualną maszynę oraz zainstalować serwer XMPP - OpenFire. Jest to wstęp do "postawienia" własnego serwera Wave. Wszystko ma na celu wykorzystanie tego rozwiązania w biznesie jako ważne narzędzie wspomagające pracę grupową.

Dla przypomnienia, aby dostać się na konsolę administracyjną należy wejść na następującą stronę: http://adres-ip-maszyny-openfire:9090. Pojawi się krótki formularz konfiguracyjny. W pierwszym kroku należy wybrać język - o dziwo aplikacja pozwala wybrać polski.

Kolejny etap dotyczy prostej konfiguracji serwera. Podajemy w tym kroku: nazwę domenową lub adres IP komputera na którym działa XMPP, numer portu konsoli administracyjnej oraz bezpieczny numer portu konsoli administracyjnej. W naszym wypadku w pierwszym polu podajemy adres IP serwera.

W następnym kroku decydujemy z sposobie przechowywania danych. Do wyboru mamy opcję zewnętrznej bazy danych oraz wewnętrznej bazy HSQLDB. Wybieramy tą drugą, ponieważ nie wymaga ona ustawiania i konfigurowania dodatkowej bazy danych. Ten wybór wpłynie jednak na wydajność całego systemu, ponieważ HSQLDB do najwydajniejszych nie należy i w porównaniu z MySQL czy PostgreSQL pozostaje daleko w tyle. Dla naszych rozwiązań jednak wystarczy.

Kolejny krok to podjęcie decyzji o tym gdzie będą przechowywane informacje o użytkownikach oraz grupach. Najlepszym i najprostszym wyjściem będzie wybór domyślnej wartości - czyli przechowywanie tych informacji w bazie danych OpenFire. Do wyboru jest również integracja z usługą katalogową (LDAP) - na pewno skorzystają z niej wszyscy, którzy posiadają takie serwisy.

Ostatnim krokiem jest wprowadzenie danych administratora: adresu email oraz hasła.

Na potwierdzenie udanej konfiguracji pojawia się komunikat zapraszający nas do zalogowania do systemu.

Zanim skorzystamy z tego zaproszenia zrestartujemy demona OpenFire: sudo /etc/init.d/openfire restart. Spróbujmy zatem zalogować się do konsoli administratora (adres: http://adres-ip-maszyny-openfire:9090 lub https://adres-ip-maszyny-openfire:9091). Powinien pojawić się nam widok jak poniżej.

Kolejnym etapem konfiguracji jest zezwolenie zewnętrznym wtyczkom na korzystanie z systemu OpenFire. W tym celu na zakładce: Ustawienia serwera -> Komponenty zewnętrzne należy włączyć usługę, podać port oraz zdefiniować hasło na podstawie którego wtyczki będą rozpoznawane i dopuszczane do działania i potwierdzić wprowadzanie zmian przyciskiem: Zapisz ustawienia.

Po zatwierdzeniu zmian pojawi się sekcja dzięki której można określić jakie komponenty mogą łączyć się z serwerem. W pierwszym kroku zaznaczyć musimy opcję: Biała lista i zapisać ustawienia. Następnie definiujemy jakie komponenty należą do tej listy. W subdomenie należy podać wave i wprowadzić hasło, a następnie zatwierdzić wybór przyciskiem: Dodaj komponent.

Kolejnym krokiem jest wprowadzenie zasad bezpieczeństwa przy podłączaniu się do serwera OpenFire. Przechodzimy na zakładkę: Serwer->Ustawienia serwera->Bezpieczeństwo i w sekcji Bezpieczne połączenia pomiędzy serwerami zaznaczamy opcję Dostosuj. Rozwinie się lista dodatkowych opcji na których sprawdzamy czy w obu przypadkach wybrane jest Dostępny/Opcjonalny. Na końcu zaznaczamy ostatni checkbox - Accept self-signed certificates. Server dialback over TLS is now available i akceptujemy wprowadzone zmiany klikając przycisk Zapisz ustawienia.

Teoretycznie to by było na tyle jeżeli chodzi o konfigurację serwera XMPP (OpenFire). Opcjonalnie można jeszcze wykonać kilka dodatkowych kroków, które pozwolą lepiej dostosować serwer do wymagań użytkowników. W tym momencie jednak ich nie potrzebujemy wprowadzać.