Programowanie rozproszone – DCOM
Technologia COM, której zarys i przykład zastosowania przedstawiliśmy w poprzednim rozdziale, zdobywa sobie coraz większą popularność. Coraz więcej systemowych usług Windows implementowanych jest już nie w postaci tradycyjnych interfejsów programisty (API – Application Programming Interface), lecz właśnie w formie obiektów COM. Mimo to jest ona – w swej oryginalnej postaci – dotknięta przez jedną poważną przypadłość, jaką jest ograniczenie obszaru działania do granic pojedynczego komputera: nie jest mianowicie możliwe umieszczenie klienta na komputerze innym niż serwer – dzieje się tak mimo „przezroczystego” z założenia charakteru samej technologii, to jest niewrażliwości zarówno klienta, jak i serwera na fizyczną lokalizację swego partnera.
Receptą na opisaną dolegliwość okazało się rozszerzenie technologii COM o elementy sieciowe, umożliwiające aktywowanie przez klienta zdalnych serwerów, rezydujących na innych komputerach. Owa rozszerzona postać COM, zwana rozproszonym COM i oznaczana akronimem DCOM (ang. Distributed COM), oprócz elementów komunikacji sieciowej pomiędzy komponentami wprowadza ponadto dodatkowe elementy, głównie o charakterze zabezpieczającym. Przyjrzymy się im dokładniej w tym rozdziale.
Specyfikacja DCOM to nic innego jak sieciowa wersja COM, określana niekiedy żargonowo jako „COM na drutach” (ang. wired COM). Obiekt COM osiągalny nie bezpośrednio, lecz poprzez sieć, jest obiektem DCOM. Technicznie rzecz biorąc, DCOM stanowi obiektowe rozszerzenie protokołu zdalnego wywoływania procedur (ang. RPC – Remote Procedure Calls), stworzone wraz z pojawieniem się Windows NT 4.0. Popularność tych ostatnich w zastosowaniach korporacyjnych sprawiła, iż mimo innych konkurencyjnych technologii DCOM wciąż zajmuje wiodącą pozycję; technologia ta przekroczyła już zresztą ramy samych Windows, znajdując zastosowanie w kilku wersjach UNIX-a i jako taka może być obecnie używana jako międzyplatformowe (cross–platform) rozwiązanie projektowe dla systemów rozproszonych.
DCOM wykorzystuje oryginalną koncepcję COM tzw. przezroczystej lokalizacji (ang. location transparency), co oznacza, iż wzajemne położenie fizyczne klienta i serwera jest nieistotne – mogą one rezydować na tym samym komputerze, na dwóch różnych komputerach w sieci lokalnej czy nawet – dzięki Internetowi – na różnych kontynentach. Z punktu widzenia klienta serwer DCOM zlokalizowany jest w miejscu określonym przez stosowny wpis w Rejestrze systemowym.
Ta prostota jest jednakże tylko jedną stroną medalu. Zdalny dostęp do serwera obwarowany jest wieloma regułami bezpieczeństwa, wynikającymi z tzw. sieciowego modelu domenowego (ang. Network Domain Model) – uzyskanie dostępu do obiektu COM serwera DCOM związane jest nierozerwalnie z logowaniem się klienta i weryfikacją jego tożsamości oraz uprawnień. Elementy składające się na system zabezpieczeń mogą być przy tym określane statycznie, za pomocą wpisów w Rejestrze – mamy wówczas do czynienia z bezpieczeństwem deklaratywnym – albo dynamicznie w kodzie aplikacji – co nazywane bywa bezpieczeństwem programowanym.
W tym rozdziale zobaczymy, jak C++Builder realizuje ideę bezpieczeństwa programowanego, przedstawimy też oczywiście sposoby aktywowania zdalnego obiektu DCOM.
Technologia DCOM wbudowana jest organicznie w Windows 98, Windows NT 4.0 i Windows 2000; Windows 95 wymagają w tym celu zainstalowania dodatkowego składnika o nazwie DCOM95, który można ściągnąć z firmowej witryny Microsoftu (http://www.microsoft.com/com) i który instalowany jest także wraz z Internet Explorerem w wersji 4. lub 5. (przy pełnej instalacji).
Jeżeli Twoja sieć wyposażona jest w kontroler domen (Domain Controller), powinieneś skonfigurować w swych komputerach zabezpieczenia Windows 95/98 jako zorientowane na użytkowników (user–level security); w przeciwnym razie nie będzie możliwe przeprowadzanie uwierzytelnień wywołań DCOM.
Z punktu widzenia bezpieczeństwa sieci Windows 95/98 bardzo dobrze nadają się do implementacji klientów DCOM – nie mają bowiem wbudowanych rodzimych mechanizmów zabezpieczających oraz nie mogą uruchamiać serwerów DCOM w sposób dynamiczny.
Program DCOMCnfg.exe (DCOM Configuration Utility) jest narzędziem administratora, umożliwiającym modyfikację ustawień DCOM zarówno w stosunku do pojedynczego serwera, jak i wszystkich zarejestrowanych serwerów DCOM, znajdujących się na danym komputerze. Okno główne programu (rys. 13.1) składa się z czterech następujących kart: Aplikacje, Domyślne właściwości, Domyślne zabezpieczenia i Protokoły domyślne.
Niniejsza dyskusja na temat programu DCOMCnfg.exe odnosi się do wersji znajdującej się w Windows NT 4.0 z poprawką nr 4 (Service Pack 4) lub późniejszą oraz w Windows 2000. Windows 9x posługują się nieco zmodyfikowaną wersją tego narzędzia.
Rysunek 13.1. Okno główne programu konfiguracyjnego DCOM (DCOMCnfg.exe)
Karta Aplikacje okna z rys. 13.1 zawiera wykaz wszystkich aplikacji, z którymi związane są zarejestrowane serwery DCOM istniejące na danym komputerze. Po wybraniu określonego serwera i kliknięciu przycisku Właściwości uzyskujemy dostęp do jego ustawień.
Za pośrednictwem karty Domyślne właściwości (rys. 13.2) możliwe jest m.in. udostępnienie albo zablokowanie mechanizmów DCOM na danym komputerze, a także określenie domyślnych dla danego komputera ustawień uwierzytelnień i uosobienia.
Jedna z opcji tej karty określa dostępność internetowych usług COM (CIS – COM Internet Services) na danym komputerze. Usługi te wprowadzają do modelu DCOM nowe elementy, jak np. komunikację za pośrednictwem serwerów proxy i firewalli. Więcej informacji na temat usług CIS znajduje się na firmowej stronie Microsoftu pod adresem http://msdn.microsoft.com/library/backgrnd/html/cis/htm.
Rysunek 13.2. Domyślne ustawienia DCOM na określonym komputerze
Uwierzytelnienie może być określone na jednym z trzech następujących poziomów:
· dla pierwszego połączenia klienta;
· dla każdego wywołania metody serwera;
· dla każdego przesłania pakietu pomiędzy klientem a serwerem.
Można także całkowicie wyłączyć uwierzytelnianie, co jakkolwiek jest nieco ryzykowne, to jednak mogą na tym skorzystać niektórzy użytkownicy, szczególnie ci łączący się z serwerem za pośrednictwem Internetu.
Domyślny poziom uosobienia to poziom uprawnień, jakie przyznawane są aplikacji serwera przez aplikację klienta do wykonywania określonych działań w imieniu tej ostatniej. Poziom tych uprawnień może przyjmować następujące wartości, w kolejności od najniższego do najwyższego zabezpieczenia:
· Anonimowy – tożsamość aplikacji klienta nie jest znana serwerowi;
· Identyfikacja – aplikacja serwera może sprawdzić tożsamość aplikacji klienta;
· Uosobienie – aplikacja serwera może personifikować aplikację klienta dla dostępu w jej imieniu do lokalnych zasobów komputera;
· Delegat – aplikacja serwera może wykonywać określone działania na innych komputerach jako aplikacja klienta. Ten wariant uosobienia dostępny jest tylko w Windows 2000 z uruchomionym systemem Kerberos.
Na karcie Domyślne zabezpieczenia (rys. 13.3) możliwe jest określenie domyślnych uprawnień dostępu do aplikacji, uruchamiania aplikacji i konfiguracji OLE.
Rysunek 13.3. Ustawienia domyślnych zabezpieczeń DCOM
Domyślne uprawnienia dostępu określają, kto ma prawo dostępu do serwerów DCOM zarejestrowanych na komputerze. Wartość Wszyscy (Everyone) oznacza dostęp dla każdego użytkownika.
Domyślne uprawnienia uruchamiania dotyczą praw do uruchamiania procesów serwera; wartość Wszyscy (Everyone) oznacza dowolnego użytkownika. Ta opcja nie może być ustawiana w sposób programowy.
Domyślne uprawnienia konfigurowania związane są z instalacją nowych serwerów OLE i zmianami w serwerach istniejących i określają rodzaj dostępu (Czytaj, Pełny dostęp, Specjalny dostęp) dla poszczególnych użytkowników.
Karta Protokoły domyślne (rys. 13.4) wykorzystywana jest do ustalenia dostępności i kolejności dostępu poszczególnych protokołów sieciowych używanych przez DCOM. Klikając przycisk Właściwości, można ustalić pewne aspekty funkcjonowania protokołu, na przykład dostęp za pośrednictwem firewalla. Generalnie ustawienia domyślnych protokołów nie powinny być zmieniane przez niezaawansowanych użytkowników.
Rysunek 13.4. Karta domyślnych protokołów DCOM
Nie należy zapominać, iż ustawienia dokonywane na kartach Domyślne właściwości i Domyślne zabezpieczenia są ustawieniami ogólnosystemowymi – ich zmiana może spowodować komplikację w pracy niektórych serwerów funkcjonujących dotąd bez zarzutu. O wiele bezpieczniejsze są ustawienia dokonywane w odniesieniu do konkretnego serwera.
Zmianę ustawień określonego serwera rozpoczynamy od wybrania go z listy przedstawionej na rysunku 13.1 i kliknięciu przycisku Właściwości. Wyświetlone w wyniku tego okno dialogowe właściwości serwera podzielone jest na pięć kart (rys. 13.5).
Tu proszę wkleić rysunek z pliku orig-17-05.bmp
Rysunek 13.5. Właściwości serwera DCOM
Na karcie Ogólne (rys. 13.5) widzimy zarejestrowaną nazwę serwera, jego typ, fizyczną lokalizację oraz poziom uwierzytelnień – ten ostatni może być zmieniany bez wpływu na inne serwery.
Karta Lokalizacja (rys. 13.6) umożliwia wybór komputera, na którym serwer będzie uruchamiany – mamy do dyspozycji komputer zawierający bazę danych, komputer, na którym uruchomiono program DCOMCnfg, oraz komputer o wskazanej nazwie.
Tu proszę wkleić rysunek z pliku orig-17-06.bmp
Rysunek 13.6. Lokalizacja punktu uruchomienia serwera
Karta Zabezpieczenia (rys. 13.7) jest odpowiednikiem karty zabezpieczeń domyślnych w ustawieniach ogólnosystemowych i dla każdej kategorii uprawnień (dostęp, uruchamianie, konfiguracja) umożliwia dokonanie ustawień specyficznych dla serwera bądź skorzystanie z domyślnych ustawień systemu.
Tu proszę wkleić rysunek z pliku orig-17-07.bmp
Rysunek 13.7. Ustawienia zabezpieczeń serwera
Karta Identyfikacja (rys. 13.8) służy do określenia użytkownika, w którego kontekście zabezpieczenia uruchomiona zostanie aplikacja serwera. Mamy tu do wyboru trzy opcje:
· Użytkownik aktywny – oznacza użytkownika zalogowanego do komputera („interaktywnego”); jeżeli do komputera nie jest zalogowany żaden użytkownik, próba uruchomienia aplikacji serwera zakończy się niepowodzeniem;
· Użytkownik wywołujący – oznacza użytkownika żądającego dostępu do obiektu serwera; dla każdego klienta tworzona będzie oddzielna kopia procesu serwera. Jest to ustawienie domyślne, nie jest jednak najszczęśliwsze dla aplikacji rozproszonej i jako takie powinno być unikane;
· Ten użytkownik – oznacza specyficznego użytkownika; może określać konto już zdefiniowane lub utworzone ad hoc. W większości przypadków ta opcja jest najodpowiedniejsza, dzięki niej można bowiem z góry określić zabezpieczenia uruchamianej aplikacji.
Dla każdego serwera, który nie został skonfigurowany za pomocą programu DCOMCnfg.exe, DCOM używa domyślnych ustawień systemowych zapamiętanych w Rejestrze. Specyficzne ustawienia serwera mają pierwszeństwo przed ustawieniami ogólnosystemowymi, zaś aktualne ustawienia serwera – niezależnie od tego, czy dziedziczone z ustawień ogólnosystemowych, czy też specyficzne – mogą być (z nielicznymi wyjątkami) zmieniane w sposób programowy.
Należy zawsze pamiętać o ustawieniu uprawnień uruchamiania serwera – zaniedbanie tej czynności może sprawić, iż serwer pozostanie niedostępny dla zdalnych użytkowników.
Tu proszę wkleić rysunek z pliku orig-17-08.bmp
Rysunek 13.8. Identyfikacja użytkownika uruchamiającego aplikację serwera
Nie będziemy się tu zajmować kartą Punkty końcowe – zainteresowanych Czytelników odsyłamy do systemu pomocy programu DCOMCnfg.
Prezentację mechanizmów DCOM przeprowadzimy na podstawie dwóch projektów, zlokalizowanych w podkatalogach Server i Client katalogu głównego o nazwie EasyDCOM. Kompletny kod źródłowy obydwu projektów znajduje się na załączonej do książki płycie CD-ROM.
Rozpoczniemy od projektu serwera. W tym celu:
1. Zainicjuj nową aplikację (File|New Application).
2. Przejdź do folderu EasyDCOM\Server i zapisz projekt pod nazwą EasyDCOM.bpr, a jego moduł główny pod nazwą MainUnit.cpp.
3. Za pomocą inspektora obiektów ustaw nazwę formularza na frmMain, a następnie umieść na nim stosowną etykietę i zmień jego rozmiary tak, by wyglądał podobnie do rysunku 13.9
Tu proszę wkleić rysunek z pliku orig-17-09.bmp
Rysunek 13.9. Formularz główny serwera
4. Wyświetl okno New Items (File|New), przejdź na jego kartę ActiveX i kliknij dwukrotnie pozycję Automation Object.
5. Zostanie wyświetlone okno dialogowe New Automation Object. Wpisz HostInfo jako nazwę koklasy i „Easy DCOM Library 1.0” w pole Description. Kliknij przycisk OK.
6. Za pomocą opcji View|Type Library uczyń okno edytora TLE oknem pierwszoplanowym. W jego lewym panelu podświetl pozycję reprezentującą interfejs IHostInfo.
7. Rozwiń listę stowarzyszoną z przyciskiem New Property na pasku narzędziowym (drugi od lewej w prawej sekcji przycisków) i wybierz z niej opcję Read Only.
8. Zmień domyślną nazwę nowej właściwości (Property1) na Info.
9. Na prawym panelu przejdź do karty Parameters i zmień typ parametru na BSTR* (patrz rys. 13.10)
Tu proszę wkleić rysunek z pliku orig-17-10.bmp
Rysunek 13.10. Właściwość Info w oknie edytora TLE
10. Kliknij przycisk Refresh na pasku narzędziowym w celu odświeżenia zawartości plików źródłowych.
11. Przejdź do pliku HostInfoImpl.cpp i dodaj następujący kod do metody get_Info():
STDMETHODIMP THostInfoImpl::get_Info(BSTR* Value)
{
try {
*Value = NULL;
char lpBuffer[MAX_COMPUTERNAME_LENGTH + 1];
unsigned long lngSize = sizeof(lpBuffer);
if (GetComputerName(lpBuffer, &lngSize) == 0)
return HRESULT_FROM_WIN32(GetLastError());
WideString strInfo = AnsiString().sprintf("Date and time at %s is:
%s", lpBuffer, DateTimeToStr(Now()));
*Value = strInfo.Detach();
}
catch(Exception &e) {
return Error(e.Message.c_str(), IID_IHostInfo);
return S_OK;
};
12. Skompiluj i uruchom serwer (naciskając F9).
Zatrzymajmy się przez chwilę przy funkcji THostInfoImpl::get_Info(). Rozpoczyna się ona wywołaniem funkcji Win32 API GetComputerName(), wpisującej nazwę komputera do zmiennej lpBuffer. Nazwa ta, po uzupełnieniu jej o bieżącą datę i czas, wpisywana jest do pomocniczego łańcucha strInfo. Zawartość tego łańcucha zostaje następnie przepisana do parametru Value i jednocześnie od niego „odczepiona”, by po zakończeniu funkcji nie została zwolniona zajmowana przez nią pamięć – jak pamiętamy z rozdziału 12., parametry wyjściowe (out) alokowane są przez serwer i zwalniane przez klienta.
Scenariusz tworzenia naszej przykładowej aplikacji – klienta DCOM jest następujący:
1. Zainicjuj nową aplikację i zapisz jej pliki w katalogu ...
maciejle1