tehnike raspodijeljenog programiranja u sustavu sa...

SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Ivan Janeš

Tehnike raspodijeljenog programiranja u sustavu sa sigurnosnom stijenom

MAGISTARSKI RAD

Zagreb, 2005.

Magistarski rad je izrađen u Mentor: Doc. dr. sc. Marin Golub Magistarski rad ima: 109 stranica Rad br.:

SADRŽAJ 1. UVOD...................................................................................................................1 2. POZIVI UDALJENIH PROCEDURA ZASNOVANI NA NORMI ONC RPC .........3

2.1. UVOD .............................................................................................................3 2.2. MODEL POZIVA UDALJENE PROCEDURE .............................................................4 2.3. STRUKTURA PORUKA .......................................................................................5

2.3.1. Sadržaj poruka.......................................................................................6 2.3.2. Poruka poziva ........................................................................................6 2.3.3. Poruka odgovora ...................................................................................7

2.4. AUTENTIFIKACIJA.............................................................................................9 2.4.1. Protokol autentifikacije...........................................................................9 2.4.2. NULL autentifikacija.............................................................................10 2.4.3. UNIX autentifikacija .............................................................................10

3. ARHITEKTURA ZASNOVANA NA NORMI CORBA ........................................11 3.1. UVOD ...........................................................................................................11 3.2. ARHITEKTURA NORME CORBA.......................................................................11 3.3. STRUKTURA ORB POSREDNIKA ......................................................................13

3.3.1. Stub objekti klijenta..............................................................................14 3.3.2. Sučelje dinamičkog poziva ..................................................................14 3.3.3. Implementacijski skeleton....................................................................15 3.3.4. Sučelje dinamičkog skeleton-a ............................................................15 3.3.5. Adapter objekta....................................................................................15

3.4. JEZIK ZA DEFINIRANJE SUČELJA ......................................................................15 3.5. PROTOKOL IIOP............................................................................................16

3.5.1. Sintaksa prijenosa CDR.......................................................................16 3.5.2. Formati poruka.....................................................................................17 3.5.3. Prijenos poruka prema protokolu GIOP ...............................................18

3.6. SIGURNOSNA USLUGA....................................................................................19 3.6.1. Sigurnosni model .................................................................................19

4. POZIVI UDALJENIH METODA U PROGAMSKOM OKRUŽENJU JAVA ........21 4.1. UVOD ...........................................................................................................21 4.2. ARHITEKTURA RMI ........................................................................................21

4.2.1. Stub/skeleton sloj.................................................................................22 4.2.2. Sloj udaljene reference ........................................................................22 4.2.3. Prijenosni sloj.......................................................................................23

4.3. SAKUPLJANJE SMEĆA.....................................................................................23 4.4. PROTOKOL JRMP .........................................................................................24

4.4.1. Format izlaznog toka ...........................................................................25 4.4.2. Format ulaznog toka ............................................................................26 4.4.3. Serijalizacija objekta ............................................................................27 4.4.4. Korištenje protokola HTTP POST........................................................27

4.5. SIGURNOST U JAVA OKRUŽENJU .....................................................................28 4.5.1. Vrste sigurnosnih dozvola....................................................................28 4.5.2. Sigurnosni upravitelj ............................................................................30

4.5.3. Datoteke sigurnosne politike................................................................31 4.5.4. Java usluga autentifikacije i autorizacije ..............................................32

5. ARHITEKTURA ZASNOVANA NA MICROSOFTOVOM MODELU DCOM......34 5.1. UVOD ...........................................................................................................34 5.2. ARHITEKTURA DCOM....................................................................................34 5.3. PAKIRANJE PARAMETARA ...............................................................................36

5.3.1. Vrste pakiranja parametara..................................................................36 5.3.2. Pakiranje parametara pomoću biblioteke tipova ..................................36 5.3.3. Standardno pakiranje parametara .......................................................36 5.3.4. Korisničko pakiranje parametara .........................................................37

5.4. PROTOCOL ORPC ........................................................................................38 5.4.1. Pakiranje globalnog jedinstvenog identifikatora ...................................38 5.4.2. Pozivi udaljenog objekta ......................................................................39

5.5. SIGURNOST U DCOM OKRUŽENJU..................................................................41 5.5.1. Sigurnost u Windows NT okruženju.....................................................41 5.5.2. Sigurnost u COM okruženju.................................................................42

6. RASPODIJELJENO PROGRAMIRANJE U MICROSOFT .NET OKRUŽENJU43 6.1. UVOD ...........................................................................................................43 6.2. .NET REMOTING ARHITEKTURA ......................................................................43

6.2.1. Stvaranje zamjenskog objekta .............................................................44 6.2.2. Stvaranje poruke..................................................................................45 6.2.3. Ponori poruka ......................................................................................46 6.2.4. Klijent/poslužitelj-aktivirani objekti........................................................48

6.3. UPRAVLJANJE ŽIVOTNIM VIJEKOM OBJEKTA ......................................................49 6.4. .NET REMOTING SIGURNOST .........................................................................51

6.4.1. Autentifikacija.......................................................................................51 6.4.2. Autorizacija ..........................................................................................51 6.4.3. Sigurni prijenos podataka ....................................................................52

7. OSTALE TEHNIKE............................................................................................53 7.1. WEB USLUGA ................................................................................................53 7.2. XML-RPC....................................................................................................54 7.3. TEHNIKA PARALELNOG PROGRAMIRANJA RAZMJENOM PORUKA ..........................55

8. USPOREDBE TEHNIKA RASPODIJELJENOG PROGRAMIRANJA ..............58 8.1. OPIS PROBLEMA............................................................................................58 8.2. KORIŠTENA PROGRAMSKA I STROJNA POTPORA................................................58 8.3. POJEDINA SVOJSTVA USPOREDBE ...................................................................59

8.3.1. Efikasnost ............................................................................................59 8.3.2. Stabilnost / prenosivost / lakoća programiranja ...................................64 8.3.3. Sigurnost raspodijeljenog sustava .......................................................69 8.3.4. Usporedba sigurnosnih mehanizama raspodijeljenih tehnika ..............72

9. RASPODIJELJENO PROGRAMIRANJE U OKRUŽENJU ZAŠTIĆENIM SIGURNOSNOM STIJENOM ...................................................................................74

9.1. UVOD ...........................................................................................................74 9.2. VRSTE SIGURNOSNIH STIJENA.........................................................................75

9.2.1. Filtriranje paketa ..................................................................................75 9.2.2. Pristupnici na aplikacijskoj razini..........................................................76

9.3. RASPODIJELJENE TEHNIKE I SIGURNOSNE STIJENE............................................78 9.3.1. Problem zaobilaženja sigurnosne stijene.............................................78 9.3.2. HTTP tuneliranje..................................................................................78 9.3.3. Zamjenski poslužitelj............................................................................79 9.3.4. Dvosmjerni komunikacijski kanal .........................................................79

10. DVOSMJERNI .NET REMOTING KOMUNIKACIJSKI KANAL.....................81 10.1. UVOD .......................................................................................................81 10.2. IMPLEMENTACIJA DVOSMJERNOG KANALA.....................................................81

10.2.1. Klase za komunikaciju između klijenta i poslužitelja ............................81 10.2.2. Struktura poruke prijenosnog kanala ...................................................82 10.2.3. Arhitektura kanala................................................................................82 10.2.4. Inicijalizacija veze na strani klijenta .....................................................86 10.2.5. Inicijalizacija veze na strani poslužitelja...............................................88 10.2.6. Prijenosni rukovatelj.............................................................................90

10.3. DEMONSTRACIJA ZAOBILAŽENJA SIGURNOSNE STIJENE..................................93 11. ZAKLJUČAK .................................................................................................97 LITERATURA ...........................................................................................................98 POPIS KRATICA....................................................................................................101 SAŽETAK ...............................................................................................................104 SUMMARY..............................................................................................................105 ŽIVOTOPIS.............................................................................................................106

1

1. Uvod

Sklopovske platforme, na kojima su izvođeni izvršni programi, neprestano su se razvijale i međusobno konkurirale. Asemblerski pristup pisanju programa, koji je ograničen platformom, nije omogućavao izvođenje istog izvršnog programa na različitim platformama. Postepeno, strukturni programski jezici kao FORTRAN i COBOL pružali su programerima učinkovitije korištenje svojeg vremena rješavajući ih potrebe pisanja svakog novog programa od samog početka. Ponovno korištenje izvornog teksta programa učinilo je ustupak bibliotekama koje su predstavljale velike skupove rutina i podrutina. Ove biblioteke, zajedno s programima koji su ih koristili, rasle su sve više i više sve do trenutka kada bi postale problem za održavanje. Svojedobno, objektno orijentirano programiranje (OOP) riješilo je mnogo problema vezanih za strukturno programiranje. Umjesto velike isprepletene mreže funkcija, OOP dozvoljava programske sustave građene od diskretnih programskih modula. Veći dio funkcionalnosti objekta je skriven i samo su javni dijelovi dostupni vanjskom svijetu. Dobro dizajniran sustav je moguće lako razumjeti budući je većina detalja oko samog rada objekata sakrivena. Također, agregacija i nasljeđivanje dozvoljavaju stvaranje novih objekata jednostavnim korištenjem i modifikacijom postojećih objekata. Ponovna iskoristivost programskih modula još uvijek nije na dovoljno visokoj razini jer je većina objekata dizajnirana za rad unutar inicijalnog sustava. S brzim razvojem programskih sustava, objekti su se često ponašali drugačije od očekivanja programera. Rijetko se uspijevalo jednostavno integrirati postojeći objekt u nove sustave. Sljedeći korak u evoluciji razvoja programske opreme je razvoj zasnovan na komponentama. Razvoj zasnovan na komponentama razbija skup funkcionalnosti na klijenta, sučelje i implementaciju. Klijent predstavlja dio programskog sustava kojem je potreban skup mogućnosti. Skup mogućnosti je definiran kao sučelje. Implementacija jednostavno djeluje kao poslužitelj koji podupire ovo sučelje. Glavna razlika između razvoja zasnovanog na sučelju i OOP-a je u tome što je sučelje više nalik na ugovor. U trenutku kada se uspostavi, klijent ga očekuje a poslužitelj ga mora jednoznačno podržavati. Sada je moguće objekte i komponente smjestiti na odvojena računala ili platforme. Objekti i komponente međusobno komuniciraju preko heterogene mreže. Ovo omogućuje raspodijeljeno računarstvo. Neke od najvažnijih paradigmi raspodijeljenog računarstva su ONC RPC (engl. Open Network Computing Remote Procedure Call), CORBA (engl. Common Object Request Broker Architecture), Java RMI (engl. Java Remote Method Invocation), DCOM (engl. Distributed Component Object Model) i nasljednik DCOM-a .NET Remoting [17]. U ovom radu opisane su sve navedene tehnike, s posebnim naglaskom na .NET Remoting. Ukratko su spomenute Web usluge, XML-RPC i MPI (engl. Message Passing Interface). Također, provedena je usporedba tehnika s obzirom na učinkovitost, stabilnost, prenosivost, lakoću programiranja i sigurnost. Prema Tanenbaumu, raspodijeljeni sustav je skup međusobno nezavisnih računala koji se korisnicima sustava prikazuje kao jedno računalo [4]. Drugim riječima, područje izvršavanja raspodijeljene aplikacije se proteže preko više računala. Štoviše, cilj arhitekture raspodijeljene aplikacije je poboljšanje učinkovitosti. Idealna

2

raspodijeljena aplikacija može se jednostavno proširiti na posluživanje tisuća istovremenih klijenata dodavanjem računala. Postoje i drugi razlozi za primjenu raspodijeljene arhitekture, kao na primjer:

- Za integraciju izvršnog programa koji se izvršava u različitim okruženjima, na različitim operacijskim sustavima i platformama.

- Za pružanje sinkronizacije i komunikacije u stvarnom vremenu između brojnih klijenata (npr. chat poslužitelj). Implementacija ovakvog dizajna u obliku tradicionalnog poslužitelja oslanjala bi se na veliko korištenje baze podataka i učestalo prozivanje, što bi onemogućilo posluživanje velikog broja korisnika.

- Za podržavanje tankih klijenata (npr. programska potpora na embedded, odnosno ugrađenim uređajima) koji nemaju dovoljno procesne moći za svoje podatkovne potrebe.

U današnje vrijeme, sigurnost i zaštita podataka informacijskog sustava neke tvrtke predstavljaju de facto jednu od glavnih smjernica implementacije raspodijeljenog sustava. U takvom okruženju, zaštićenom sigurnosnim stijenama na različitim razinama, pojavljuje se problem prilikom dvosmjerne komunikacije klijenata s poslužiteljem izvan lokalne mreže. U ovom su radu istraženi načini omogućavanja povratnog poziva (engl. callback) s vanjskog poslužitelja u zaštićenom sustavu, te je primjenjen novi .NET Remoting komunikacijski kanal koji omogućuje dvosmjernu komunikaciju unatoč zaštiti sigurnosnom stijenom.

3

2. Pozivi udaljenih procedura zasnovani na normi ONC RPC

2.1. Uvod

Pozivi udaljenih procedura zasnovani na normi ONC RPC (engl. Open Network Computing – Remote Procedure Call) predstavljaju klijent/poslužitelj infrastrukturu koja povećava interoperabilnost, prenosivost i fleksibilnost aplikacije omogućavajući aplikaciji da bude raspodijeljena preko više heterogenih platformi. RPC smanjuje kompleksnost razvijanja aplikacija koje obuhvaćaju više operacijskih sustava i mrežnih protokola izolirajući programera od detalja vezanih uz različite operacijske sustave i mrežna sučelja. Prilikom korištenja RPC-a, pozivi lokalnih procedura predstavljaju sučelje programeru prema udaljenim procedurama. Koncept RPC-a se raspravlja u literaturi još od 1976. godine, a potpune implementacije se pojavljuju u kasnim 1970-im i ranim 1980-im [30]. Norma ONC RPC se još naziva i Sun RPC, jer je njen izvor kompanija Sun Microsystems. Protokol RPC omogućava korisnicima rad s udaljenim procedurama na isti način kao i s lokalnim. Pozivi udaljenih procedura definirani su kroz rutine sadržane u RPC protokolu. RPC protokol je protokol razmjene poruka gdje je svaka poruka poziva povezana s odgovarajućom porukom odgovora. RPC protokol također podržava procedure povratnog poziva i tzv. select podrutine na strani poslužitelja, koje daju poslužitelju mogućnost provjere stanja opisnika datoteka i redova poruka korištenih u svrhe RPC-a. Klijent se opisuje kao računalo ili proces koji pristupa uslugama ili sredstvima drugog procesa ili računala na mreži, dok se poslužitelj opisuje kao računalo koje pruža usluge i sredstva, te implementira mrežne usluge. Svaka mrežna usluga predstavlja skup udaljenih programa koji implementiraju udaljene procedure. Protokol RPC pruža proces autentifikacije koji obostrano autentificira klijenta i poslužitelja. RPC sadrži mjesto za parametre autentifikacije u svakom pozivu udaljene procedure kako bi se pozivajući program mogao autentificirati poslužitelju. Klijent strana generira i šalje parametre autentifikacije. RPC podržava različite tipove autentifikacije kao na primjer UNIX i Data Encryption Standard (DES) sustave. Svaki poslužitelj pruža program koji predstavlja skup udaljenih procedura. Kombinacija adrese poslužitelja, broja programa i broja procedure specificira točno određenu udaljenu proceduru. U RPC modelu, klijent, pozivom lokalne procedure, indirektno poziva proceduru za slanje podatkovnog paketa poslužitelju. Kada paket stigne, poslužitelj poziva rutinu usmjeravanja, obavi poziv nad zahtijevanom udaljenom procedurom te pošalje odgovor klijentu. Lokalni poziv procedure tada vraća rezultat klijentu. RPC sučelje se obično koristi za komunikaciju između procesa na različitim računalima na mreži. Međutim, RPC funkcionira jednako uspješno i između različitih procesa na istom računalu.

4

2.2. Model poziva udaljene procedure

Model poziva udaljene procedure sličan je modelu poziva lokalne procedure. U lokalnom modelu, pozivatelj stavlja argumente procedure na stog te prenese kontrolu proceduri. Pozivatelj naposljetku preuzme kontrolu, dohvati rezultate procedure te nastavi s izvođenjem. RPC funkcionira na sličan način, u kojem se glavna dretva proteže logički preko dva procesa: procesa pozivatelja i procesa poslužitelja. Prvo, proces pozivatelja pošalje poruku poziva, koja sadrži parametre procedure, procesu poslužitelja. Zatim, proces pozivatelja čeka na poruku odgovora (blokira svoje izvođenje). Proces na strani poslužitelja, koji čeka na poruku poziva, izvuče parametre procedure, izračuna rezultat i pošalje poruku odgovora. Poslužitelj tada čeka na sljedeću poruku poziva. Naposljetku, proces pozivatelja primi poruku odgovora, izvuče rezultate procedure i nastavi izvršavanje. RPC paradigma ilustrirana je na slici 2.1 [23].

Proces klijenta Proces poslužitelja

Klijent

RPC biblioteka izvršnog okruženja

Poslužitelj stub

Procedure upravljača

RPC biblioteka izvršnog okruženja

Klijent stub

poziv

odgovor

Sučelje

mrežne poruke

prividni tok

pozivodgovor poziv

odgovor

pozivodgovor poziv

odgovor

Slika 2.1: Tok poziva udaljene procedure

Tehnika RPC postiže transparentnost putem kombinacije stub-ova na strani klijenta i poslužitelja. Stub* na strani klijenta implementira lokalnu verziju udaljene procedure te je ta procedura upravo ona koju klijent poziva. Ova procedura pakira parametre

* Zamjenski programski element.

5

poziva u poruku poziva (engl. marshalling) koju proslijeđuje preko mreže stub-u poslužitelja, koji obavlja pravi poziv ciljne procedure. Kada odgovor stigne stub-u klijenta, on ga raspakira (engl. unmarshalling) te stavi povratnu vrijednost u registar, ukloni povratnu adresu sa stoga i prenese kontrolu natrag pozivatelju. Protokol RPC nezavisan je o prijenosnim protokolima. Kako se poruka prenosi iz jednog procesa u drugi je neovisno o RPC operacijama. Protokol se odnosi samo na specifikaciju i interpretaciju poruka. RPC ne implementira pouzdanost, što je razlog zbog čega aplikacija mora biti svjesna vrste prijenosnog protokola ispod RPC razine. Ako se aplikacija izvršava iznad pouzdanog prijenosnog protokola, kao što je protokol Transmission Control Protocol/Internet Protocol (TCP/IP), tada je većina posla već obavljena. U suprotnom, ako se radi o primjerice manje pouzdanom prijenosu kao što je protokol User Datagram Protocol (UDP), aplikacija mora implementirati pravila retransmisije i isteka mjerača vremena (engl. timer) jer protokol RPC ne pruža takve usluge. Svaki RPC zahtjev sadrži transakcijski ID. Kako bi se do određene razine osiguralo poštivanje pravila koje dozvoljava samo jednostruko izvršavanje zahtjeva, RPC dozvoljava poslužitelju korištenje transakcijskog ID-a za pregled prethodno pristiglih zahtjeva. Poslužitelj tada ima mogućnost odbijanja pojedinih zahtjeva koji su već prethodno zaprimljeni. RPC klijent uglavnom koristi transakcijski ID za spajanje odgovora sa zahtjevima. Prilikom korištenja pouzdanog protokola poput protokola TCP/IP, aplikacija može zaključiti iz poruke odgovora da je procedura izvršena točno jedanput. Ako aplikacija ne primi poruku odgovora, pretpostavka da udaljena procedura nije izvršena ne mora biti valjana. Zbog toga, aplikacija uvijek treba voditi računa o isteku mjerača vremena i ponovnom povezivanju prilikom obrade gubitka veze s poslužiteljem. Također, mogu biti korišteni i drugi prijenosni protokoli osim UDP-a i spojnih protokola. Na primjer, protokol tipa zahtjev/odgovor, kao što je protokol Versatile Message Transaction Protocol (VMTP), je možda najprirodniji prijenosni protokol za tehniku RPC [23].

2.3. Struktura poruka

Protokol RPC sastoji se od dvije distinktne strukture: poruke poziva i poruke odgovora. Nakon poziva udaljene procedure nad mrežnim poslužiteljem, klijent primi odgovor koji sadrži rezultate izvršavanja procedure. Pružajući jedinstvenu specifikaciju za udaljenu proceduru, RPC može pravilno spojiti poruku odgovora sa svakom porukom poziva (ili zahtjeva). RPC protokol je definiran korištenjem jezika za opis podataka eXternal Data Representation (XDR), koji uključuje strukture, enumeracije i unije, te su detalji protokola RPC u nastavku izraženi upravo putem jezika XDR [28].

6

2.3.1. Sadržaj poruka Opća struktura RPC poruke prikazana je na slici 2.2.

struct rpc_msg { unsigned int xid; union switch (enum msg_type mtype) { case CALL: call_body cbody; case REPLY; reply_body rbody; } body; };

Slika 2.2: Struktura RPC poruke

Sve RPC poruke poziva i odgovora započinju s transakcijskim identifikatorom xid, iza kojeg slijedi tijelo poruke čija struktura ovisi o vrsti poruke. Vrsta poruke je definirana enumeracijom msg_type, koja može biti jedna od sljedećih vrijednosti: CALL – poziv ili REPLY – odgovor. Enumeracija msg_type ima sljedeću definiciju:

enum msg_type { CALL = 0, REPLY = 1 };

Slika 2.3: Enumeracija vrste poruke

Parametar xid koristi se na strani klijenata za spajanje poruke odgovora s porukom poziva ili na strani poslužitelja za otkrivanje retransmisija. Poslužitelj ne tretira parametar xid kao sekvencijski broj. Inicijalna struktura RPC poruke praćena je tijelom poruke. Tijelo poruke poziva ima jedinstven oblik, dok tijelo poruke odgovora može poprimiti dva različita oblika ovisno o prihvaćenosti poziva od strane poslužitelja.

2.3.2. Poruka poziva Svaka poruka poziva udaljene procedure sadrži sljedeća polja tipa unsigned int za jednoznačno identificiranje udaljene procedure:

- Broj programa - Broj verzije programa - Broj procedure

Tijelo RPC poruke poziva poprima oblik prikazan na slici 2.4. struct call_body { unsigned int rpcvers; unsigned int prog; unsigned int vers; unsigned int proc; opaque_auth cred; opaque_auth verf; 1 parameter 2 parameter . . . };

Slika 2.4: Tijelo RPC poruke poziva

7

Parametri ove strukture su:

- rpcvers – Specificira broj verzije RPC protokola.

- prog – Specificira broj koji identificira udaljeni program. Ovaj broj definira potreban program za izvršavanje udaljene procedure. Brojevi programa su administrirani u centralnoj autoritativnoj jedinici i dokumentirani u specifikaciji usluga programa.

- vers – Specificira broj koji identificira verziju udaljenog programa. Brojevi verzija se pridjeljuju za identificiranje različitih stadija u razvoju usluga programa. Poslužitelji mogu istovremeno posluživati zahtjeve za različitim verzijama iste usluge.

- proc – Specificira broj procedure povezane s pozivanim udaljenim programom. Ovi brojevi također su dokumentirani u specifičnoj dokumentaciji programskih usluga.

- cred – Specificira autentifikacijski parametar (akreditaciju) koji identificira pozivatelja kao onoga koji ima pravo na poziv udaljenog programa. Ovaj parametar šalje se kao transparentna podatkovna struktura što znači da se ne interpretira od strane RPC infrastrukture prilikom prijenosa od klijenta do poslužitelja.

- verf – Specificira verifikator, odnosno skraćeni autentifikacijski parametar, koji identificira pozivatelja poslužitelju. Ovaj parametar se također šalje kao transparentna podatkovna struktura i generira ga poslužitelj.

- 1 parameter i 2 parameter – Predstavljaju parametre specifične za proceduru.

Klijent ima mogućnost slati pakete svima na mreži (engl. broadcast) i čekanja na brojne odgovore od različitih poslužitelja. Također, klijent može poslati poslužitelju proizvoljno veliki slijed poruka poziva u batch načinu komunikacije, što ujedno i identificira mogućnost RPC protokola za asinkronim pozivom udaljenih procedura.

2.3.3. Poruka odgovora Poruka odgovora RPC protokola varira ovisno o tome da li je poruka poziva prihvaćena ili odbijena od strane mrežnog poslužitelja. RPC poruka odgovora može biti jedna od sljedeće dvije vrste definirane enumeracijom reply_stat:

enum reply_stat stat { MSG_ACCEPTED = 0, MSG_DENIED = 1 };

Slika 2.5: Enumeracija oblika poruke odgovora

RPC poruka odgovora za prihvaćen zahtjev od strane mrežnog poslužitelja ima strukturu prikazanu na slici 2.6.

struct accepted_reply areply { opaque_auth verf; union switch (enum accept_stat stat) { case SUCCESS: opaque results {0}; /* specificni rezultati za proceduru pocinju ovdje */ case PROG_MISMATCH:

8

struct { unsigned int low; unsigned int high; } mismatch_info; default: void; } reply_data; };

Slika 2.6: RPC poruka odgovora za prihvaćen zahtjev

Strukture unutar prihvaćene poruke odgovora su:

- opaque_auth verf – Autentifikacijski verifikator generiran od strane poslužitelja u korist svoje identifikacije pozivatelju ili skraćena verzija strukture akreditacije pozivatelja (ako je riječ o UNIX autentifikaciji).

- enum accept_stat stat – Enumerator koji daje status prihvaćene poruke zahtjeva.

Enumeracijski tip podatka accept_stat ima definiciju prikazanu na slici 2.7. enum accept_stat { SUCCESS = 0, /* RPC je uspješno izveden */ PROG_UNAVAIL = 1, /* poslužitelj nije eksportirao traženi program */ PROG_MISMATCH = 2, /* poslužitelj ne podržava traženu verziju */ PROC_UNAVAIL = 3, /* program ne podržava traženu proceduru */ GARBAGE_ARGS = 4, /* procedura ne može dekodirati parametre */ };

Slika 2.7: Status prihvaćene poruke zahtjeva

Poruka poziva može biti odbijena od poslužitelja iz dva razloga: poslužitelj ne koristi kompatibilnu verziju RPC protokola ili postoji autentifikacijska pogreška. RPC poruka odgovora na zahtjev odbijen od mrežnog poslužitelja ima sljedeću strukturu:

struct rejected_reply rreply { union switch (enum reject_stat stat) { case RPC_MISMATCH: struct { unsigned int low; unsigned int high; } mismatch_info; case AUTH_ERROR: enum auth_stat stat; } };

Slika 2.8: RPC poruka odgovora za odbijen zahtjev

Parametar enum reject_stat može predstavljati dvije vrijednosti, RPC_MISMATCH i AUTH_ERROR, te ima definiciju prikazanu na slici 2.9.

enum reject_stat { RPC_MISMATCH = 0, /* RPC verzija je razlicita od 2 */ AUTH_ERROR = 1, /* poslužitelj ne može autentificirati pozivatelja */ };

Slika 2.9: Status odbijene poruke zahtjeva

9

Enumeracija auth_stat se vraća u slučaju da poslužitelj ne uspije autentificirati pozivatelja. Mogući statusi su prikazani na slici 2.10.

enum auth_stat { AUTH_BADCRED = 1, /* kriva identifikacija */ AUTH_REJECTEDCRED = 2, /* zapo ni novu sjednicu */ AUTH_BADVERF = 3, /* krivi verifikator */ AUTH_REJECTEDVERF = 4, /* istekao verifikator */ AUTH_TOOWEAK = 5, /* odbijen zbog sigurnosti */ };

Slika 2.10: Status neuspjele autentifikacije na strani poslužitelja

2.4. Autentifikacija

Pozivatelj se ne mora htjeti identificirati poslužitelju, a poslužitelj ne mora tražiti ID od pozivatelja. Međutim, neke mrežne usluge, kao na primjer mrežni datotečni sustav (engl. Network File System – NFS), zahtijevaju veću sigurnost. Protokol RPC definira samo autentifikaciju, a ne i kontrolu pristupa individualnim uslugama odnosno autorizaciju. Svaka usluga mora implementirati svoja pravila kontrole pristupa i obznaniti ih kroz povratne statuse u svom protokolu. Programer može dograditi nad autentifikacijom poruka dodatnu sigurnost i kontrolu pristupa.

2.4.1. Protokol autentifikacije Predlošci protokola za autentifikaciju pozivatelja poslužitelju i obratno definirani su kao dio protokola RPC. Svaki poziv udaljene procedure autentificiran je na strani poslužitelja. U tu svrhu, RPC klijent generira i šalje parametre autentifikacije. Poruka poziva ima dva autentifikacijska polja: akreditaciju i verifikator. Poruka odgovora s druge strane ima samo jedan i to verifikator odgovora. Specifikacija protokola RPC, prikazana na slici 2.11, definira kao transparentni tip podatka akreditaciju poruke poziva i verifikator poruke poziva i odgovora.

enum auth_flavor { AUTH_NULL = 0, AUTH_UNIX = 1, AUTH_SHORT = 2, AUTH_DES = 3 }; struct opaque_auth { auth_flavor flavor; opaque body<400>; };

Slika 2.11: Enumeracija protokola i struktura tijela autentifikacije

Svaka struktura opaque_auth sadrži enumeraciju auth_flavor iza koje slijede okteti transparentni prema implementaciji RPC protokola. Interpretacija i semantika podataka sadržanih unutar autentifikacijskih polja definirani su pojedinim, neovisnim specifikacijama autentifikacijskih protokola. Ako su autentifikacijski parametri odbijeni, poruke odgovora definiraju razloge. Poslužitelj može podržavati više vrsta autentifikacije istovremeno.

10

2.4.2. NULL autentifikacija Ponekad, RPC pozivatelj ne zna svoj identitet ili poslužitelj ne treba znati identitet pozivatelja. U ovim slučajevima, tip autentifikacije AUTH_NULL može se koristiti i u poruci poziva i u porukama odgovora. Okteti strukture opaque_auth nisu definirani, te bi duljina trebala biti 0.

2.4.3. UNIX autentifikacija Proces koji poziva udaljenu proceduru može se identificirati na principu UNIX sustava, te tada za akreditaciju koristi tip autentifikacije AUTH_UNIX. Okteti strukture opaque_auth kodiraju sljedeće:

struct auth_unix { unsigned stamp; /* ID generiran radnom stanicom pozivatelja */ string machinename; /* ime radne stanice pozivatelja; do 255 okteta duljine */ unsigned uid; /* korisnicki ID pozivatelja */ unsigned gid; /* ID grupe pozivatelja */ unsigned gids; /* polje ID grupa ciji je pozivatelj clan; maksimum od 10 grupa */ };

Slika 2.12: Tijelo UNIX autentifikacije

Verifikator koji prati akreditaciju treba biti postavljen na tip AUTH_NULL. Vrijednost koja definira tip autentifikacije unutar verifikatora poruke odgovora od strane poslužitelja je AUTH_NULL ili AUTH_SHORT. Ako je vrijednost AUTH_SHORT, okteti niza znakova verifikatora poruke odgovora kodiraju transparentnu strukturu. Ova transparentna struktura može tada biti poslana poslužitelju umjesto AUTH_UNIX akreditacije. Poslužitelj održava priručni spremnik (engl. cache) koji mapira skraćene transparentne strukture (vraćene u obliku AUTH_SHORT verifikatora poruke odgovora) na izvorne akreditacije pozivatelja. Ovim načinom smanjuje se mrežni promet i vrijeme obrade. Poslužitelj može eliminirati korištenje skraćene transparentne strukture u bilo kojem trenutku. Ako se ovo dogodi, RPC poruka će biti odbijena zbog autentifikacijske pogreške AUTH_REJECTEDCRED. Tada se mora koristi originalna AUTH_UNIX akreditacija pozivatelja.

11

3. Arhitektura zasnovana na normi CORBA

3.1. Uvod

Norma CORBA (engl. Common Object Request Broker Architecture) predstavlja posredničku veznu tehnologiju (engl. middleware) koja pruža integraciju, normizaciju i interoperabilnost potrebnu u današnjem heterogenom računalnom svijetu. Moderne aplikacije za upravljanje poslovanjem su tipično raspodijeljene u heterogenim okruženjima koja obuhvaćaju različita sklopovska okruženja, operacijske sustave, baze podataka i mrežne protokole. Sastoje se od komponenti napisanih u različitim programskim jezicima i često moraju integrirati puno starijih aplikacija koje bi bilo preskupo ponovno razviti ili prenijeti u drugo okruženje. Jedini način na koji se mogu eliminirati sve ove razlike je osloniti se na normirane koncepte. CORBA podržava razvoj programske opreme za ovakva heterogena okruženja uvođenjem normiranog koncepta raspodijeljenih objekata i na jasan način odvajanjem implementacije objekata od njihovih sučelja korištenjem dobro definiranog jezika Interface Definition Language (IDL). CORBA je norma za pozivanje metoda objekata preko mreže, a razvila ga je grupa Object Management Group (OMG), veliki konzorcij kompanija privrženih poboljšanju osobina raspodijeljenih objekata. Od samog početka je razvijana s ciljem podržavanja brojnih vrsta mreža, operacijskih sustava i programskih jezika. Dok CORBA, sama za sebe, nije jezik, ona uvodi novi jezik. CORBA usluge opisane su shemom, koja predstavlja predložak za metode koje objekt čini dostupnima. Takve sheme izražene su korištenjem jezika IDL. Programski jezici poput Jave, koji podržavaju normu CORBA, mogu implementirati IDL shemu te na taj način dozvoliti programskim sustavima pozivanje udaljenih metoda. IDL je jezično neutralan, što dozvoljava njegovo korištenje u svakom programskom jeziku za koje postoji IDL mapiranje.

3.2. Arhitektura norme CORBA

CORBA okruženje se sastoji od kolekcije objekata i programskih aplikacija koje funkcioniraju zajedno kao jedna cjelina. Specifikacija sheme, napisana u IDL-u, opisuje objekte namijenjene za udaljenu uporabu. Posrednik Object Request Broker (ORB) implementira sučelje između udaljenog objekta i programskog klijenta. ORB upravlja zahtjevima za uslugama objekta, a također i slanjem odgovora. Slika 3.1 prikazuje kako klijenti i poslužitelji, koji predstavljaju implementaciju usluga, komuniciraju korištenjem posrednika ORB.

12

Klijent Poslužitelj

Lokalni objekt Udaljeni objekt

Posrednik ORB

Slika 3.1: Interakcija klijenata i poslužitelja preko posrednika

Iako su objekti tretirani kao lokalni i moguće je pozivati njihove metode na uobičajen način, ipak postoji dodatni korak. ORB igra ulogu posrednika između klijenta i poslužitelja. Komunikacija između klijenta i poslužitelja odvije se preko mreže uglavnom putem protokola Internet Inter-ORB Protocol (IIOP), prikazanog na slici 3.2.

Klijent Poslužitelj

IIOP

ORB ORB

TCP/IP stog

zahtjev metode zahtjev metode odgovor metodeodgovor metode

Slika 3.2: Komunikacije putem protokola IIOP

Transparentnost zauzima centralno mjesto CORBA okruženja. Lokacijska transparentnost predstavlja sposobnost pristupa i izvođenja operacija nad CORBA objektom bez prethodnog znanja o lokaciji objekta. To implicira da bi trebalo biti

13

jednako složeno ili jednostavno izvesti operaciju nad objektom koji se nalazi na udaljenom računalu kao i pozvati metodu objekta unutar istog adresnog prostora. S druge strane, transparentnost programskog jezika pruža slobodu implementacije funkcionalnosti enkapsulirane u objektu korištenjem najprikladnijeg jezika, bilo zbog vještina programera, primjenjivosti jezika na zadatak ili izbora nekog drugog (engl. third-party) razvojnog programera koji pruža već gotove (engl. off-the-shelf) komponente. Ključ ove slobode je dakako jezik IDL.

3.3. Struktura ORB posrednika

Jezik IDL pruža sučelje koje definira što se može zahtijevati od implementacije objekta putem posrednika ORB. Ipak, IDL nije samo vodič za klijente objekata. IDL jezični procesori koriste definicije sučelja za stvaranje okruženja u kojem klijenti mogu pozivati lokalnu funkciju, a koje transparentno prema klijentu ostvaruje poziv nad ciljnim objektom na drugom računalu. Generirani izvorni tekst programa kojeg klijent koristi poznat je pod nazivom stub, dok je generirani izvorni tekst za implementaciju objekta poznat pod nazivom skeleton. Slika 3.3 prikazuje ORB jezgru, stub i skeleton te sučelja prema ORB-u [6].

Klijent Implementacija objekta

Sučelje dinamičkog

poziva

IDLstub-ovi

ORBsučelje

IDLskeleton

Sučelje dinamičkog skeleton-a

Adapterobjekta

ORB jezgra

Standardno sučelje

Generirano sučelje po tipu objekta

Mogu postojati više adaptera objekta

ORB ovisno sučelje

Slika 3.3: ORB sučelja

Stub i skeleton povezani su s njima nadređenim implementacijama klijenta i udaljenog objekta, te međusobno komuniciraju putem izvršnog okruženja ORB sustava s ciljem prosljeđivanja zahtjeva klijenata i vraćanja rezultata poziva. Ovakav

14

način rada je poznat kao statički, što znači da je IDL definiran prije samog jezičnog procesiranja, te samo operacije nad predefiniranim sučeljima mogu biti pozvane. CORBA norma također definira i sučelje koje dozvoljava dinamičko stvaranje zahtjeva za bilo koju operaciju od strane klijenta. Takvo sučelje se naziva sučelje dinamičkog poziva (engl. Dynamic Invocation Interface - DII). Na strani poslužitelja, odnosno udaljenog objekta, postoji ovome simetrično sučelje koje odgovara na takve dinamičke pozive te se naziva sučelje dinamičkog skeleton-a (engl. Dynamic Skeleton Interface - DSI). CORBA definira standardno sučelje za komunikaciju klijenta i poslužitelja s posrednikom ORB. Ovo sučelje većinom se brine oko inicijalizacije ORB-a i manipulacije referencama udaljenih objekata. Za upravljanje interakcijama s ORB-om, implementacije udaljenih objekata trebaju dodatne usluge. Komponenta pod nazivom adapter objekta (engl. Object Adapter) odgovorna je za provjeru izvodivosti pojedinog poziva te potencijalno aktiviranje udaljenog objekta u korist izvršavanja zahtjevanih operacija.

3.3.1. Stub objekti klijenta Kada klijent želi pozvati operaciju, definiranu u jeziku IDL, nad referencom objekta na način kao da se radi o lokalnoj metodi ili funkciji, mora se povezati sa stub objektima za IDL sučelje koji prosljeđuju poziv do ciljnog objekta. U objektno orijentiranim programskim jezicima stub objekti su instancirani kao lokalni zamjenski* (engl. proxy) objekti koji delegiraju pozive svojih metoda implementaciji udaljenog objekta. Stub objekti su generirani IDL jezičnim procesorom za programski jezik (i ORB okruženje) koje koristi klijent.

3.3.2. Sučelje dinamičkog poziva Unutar norme CORBA, "Zahtjev" se definira kao notacijska poruka koja se šalje objektu, identificiranim referencom objekta, kao zahtjev za pozivom određene operacije s određenim argumentima. Sučelje dinamičkog poziva (DII) definira oblik takve poruke kako bi klijenti, koji znaju za objekt preko reference i mogu odrediti njegovo sučelje, mogli kreirati zahtjeve bez potrebe za generiranje stub objekata od strane IDL jezičnog procesora. Sučelje "Zahtjeva" definirano je jezikom pseudo-IDL**, te pruža operacije za specificiranje ciljnog objekta za poziv, definiranje operacije koja se poziva i dodavanje argumenata koji se šalju. Također, implementira i metode za pozivanje tražene operacije i dohvat mogućih rezultirajućih vrijednosti. Pseudo-IDL je ostvaren u obliku biblioteke programa. Sučelje dinamičkog poziva definira različite semantike izvršavanja za operacije pozvane korištenjem pseudo-objekata, odnosno zamjenskih objekata. Dostupne su dvije vrste semantike [29]:

- Najviše-jednom (engl. at-most-once) – Zahtjev je izvršen točno jedanput ako je odgovor uspješno vraćen klijentu. U slučaju da je vraćena iznimka, zahtjev je izvršen najviše jednom.

* Surogat pravog objekta koji obavlja mrežnu komunikaciju i prosljeđuje pozive udaljenom objektu. ** Jezik za definiranje sučelja kojim se opisuju CORBA pseudo-objekti. Pseudo-objekt je sličan CORBA objektu ali se ne može koristiti kao udaljeni objekt.

15

- Najbolji-pokušaj (engl. best-effort) – Operacija koja ne vraća rezultat te pozivatelj ne zna da li je zahtjev izvršen.

3.3.3. Implementacijski skeleton Kada zahtjev dospije do poslužitelja koji pruža ostvarenja jednog ili više objekata, mora postojati način poziva prave metode nad pravom implementacijom objekta. Jezično mapiranje razvijeno za jezik implementacije se koristi prilikom translacije iz formata koji se prenosi preko žice u spremničke strukture podataka (engl. unmarshaling). Ovo se postiže skeleton objektom generiranim IDL jezičnim procesorom.

3.3.4. Sučelje dinamičkog skeleton-a Izvorni tekst ostvarenja udaljenog objekta može biti napisan u svrhu upravljanja zahtjevima na tzv. generički način, koji dinamički interpretira semantiku zahtijevane operacije te njene argumente. Ovakav način koristi posebno sučelje pod nazivom sučelje dinamičkog skeleton-a koje dopušta ostvarenju objekta pristup zahtjevu u obliku pseudo-objekta "PoslužiteljZahtjev", koji je identičan objektu "Zahtjev" ali bez operacija poziva.

3.3.5. Adapter objekta Adapter objekta je komponenta koja povezuje poslužitelje s posrednikom ORB i koju posrednik koristi za upravljanje izvršnog okruženja implementacije objekata. Kako bi se, s ciljem povećanja učinkovitosti, mogle koristiti različite komponente odgovarajuće za različite implementacije, umjesto jednostavnog proširenja standardnog sučelja prema ORB-u koristi se upravo ovaj adapter. Trenutno, CORBA definira jedno takvo sučelje pod nazivom prenosivi adapter objekta (engl. Portable Object Adapter - POA). Osnovni adapter objekta (engl. Basic Object Adapter - BOA), koji je definiran u ranijim verzijama CORBA specifikacije, potisnut je zbog nedovoljno razrađene specifikacije. Kako bi se pružila kompatibilnost unatrag s izvršnim programima starijih proizvoda, adapter objekta BOA je još uvijek podržan od brojnih implementacija posrednika ORB. Svrha adaptera objekta je generiranje i interpretiranje referenci objekata, kao i aktiviranje i deaktiviranje poslužitelja.

3.4. Jezik za definiranje sučelja

Jezik IDL je deklarativan jezik za definiranje sučelja CORBA objekata. To je jezično nezavisan način s kojim ostvarenja objekata i njihovi korisnici mogu biti sigurni u tzv. type-safe* izvođenje operacija, uz uvjet da su međusobno razmijenjene reference objekata točne. IDL se koristi u ORB specifičnim jezičnim procesorima za generiranje stub i/ili skeleton teksta programa koji konvertira podatkovne strukture u spremniku iz jednog programskog jezika u mrežne tokove i raspakira ih na drugom računalu u

* Izvorni tekst programa, koji je type-safe, ne može izvršiti operaciju nad objektom koja nije valjana za taj objekt.

16

ekvivalentne podatkovne strukture u drugom (ili istom) jeziku. Nakon što obavi poziv metode, stub/skeleton prenosi rezultate u suprotnom smjeru. Sintaksa IDL-a je većim dijelom preuzeta iz programskog jezika C++, ali sadrži različite i jednoznačne ključne riječi. Programske naredbe ne postoje budući je jedini smisao IDL-a opisivanje sučelja. Kako bi se to postiglo, podržane su sljedeće konstrukcije [6]:

- Konstante – Za pomoć pri deklaraciji tipova podataka - Deklaracije tipova podataka – U svrhu tipiziranja parametara - Atributi – Za dobavljanje i postavljanje vrijednosti određenog tipa - Operacije – Uzimaju parametre i vraćaju rezultate - Sučelja – Grupiraju tipove podataka, atribute i deklaracije operacija - Tipovi vrijednosti – Grupiraju tipove podataka, stanje i deklaracije operacija - Moduli – Za separaciju prostora nazivlja.

3.5. Protokol IIOP

Protokol IIOP predstavlja specijalizaciju ili mapiranje općeg protokola za razmjenu podataka između posrednika (engl. General Inter-ORB Protocol - GIOP) na određeni prijenosni sloj (TCP/IP). GIOP specifikacija sastoji se od sljedećih elemenata:

- Predstavljanje podataka na zajednički način (engl. Common Data Representation - CDR). CDR predstavlja sintaksu prijenosa koja mapira IDL tipove podataka na oblik (tok okteta) pogodan za prijenos između ORB posrednika.

- Formati poruka prema protokolu GIOP. GIOP poruke se razmjenjuju između agenata (klijent ili poslužitelj) u svrhu upravljanja zahtjevima za objektima, lociranjem implementacija objekata i upravljanja komunikacijskim kanalima.

- GIOP pretpostavke prijenosa. GIOP specifikacija opisuje opće pretpostavke uzete u obzir oko pitanja vezanih uz mrežni prijenosni sloj koji se može koristiti za prijenos GIOP poruka. Specifikacija također opisuje upravljanje vezama i slaganje GIOP poruka.

3.5.1. Sintaksa prijenosa CDR Protokol GIOP definira dvije međusobno različite vrste tokova okteta, poruke i enkapsulacije. Poruke su osnovne jedinice razmjene informacija u GIOP-u, dok enkapsulacije predstavljaju tokove okteta u koje IDL strukture podataka mogu biti nezavisno pakirane bez obzira na određeni kontekst poruke. Kada je struktura podataka enkapsulirana, tok okteta može biti predstavljen kao IDL transparentni tip podatka sequence<octet> koji se može tada pakirati u poruku ili drugu enkapsulaciju.

17

3.5.2. Formati poruka Protokol GIOP postavlja ograničenja na uloge klijenta i poslužitelja prema iniciranju i primanju poruka. Prema GIOP verzijama 1.0 i 1.1, klijent je agent koji otvara vezu i stvara zahtjeve, dok je poslužitelj agent koji prihvaća veze i prima zahtjeve. Kada se koristi dvosmjerni GIOP, verzije 1.2 i 1.3, bilo koja strana može otvarati veze i stvarati zahtjeve. Tipovi poruka protokola GIOP prikazani su u tablici 3.1 [29].

Tablica 3.1: Tipovi poruka protokola GIOP

Tip poruke Izvor Vrijednost GIOP verzija

Request Klijent 0 1.0, 1.1, 1.2, 1.3

Request Klijent i poslužitelj 0 1.2, 1.3

Reply Poslužitelj 1 1.0, 1.1, 1.2, 1.3

Reply Klijent i poslužitelj 1 1.2, 1.3

CancelRequest Klijent 2 1.0, 1.1, 1.2, 1.3

CancelRequest Klijent i poslužitelj 2 1.2, 1.3

LocateRequest Klijent 3 1.0, 1.1, 1.2, 1.3

LocateRequest Klijent i poslužitelj 3 1.2, 1.3

LocateReply Poslužitelj 4 1.0, 1.1, 1.2, 1.3

LocateReply Klijent i poslužitelj 4 1.2, 1.3

CloseConnection Poslužitelj 5 1.0, 1.1, 1.2, 1.3

CloseConnection Klijent i poslužitelj 5 1.2, 1.3

MessageError Klijent i poslužitelj 6 1.0, 1.1, 1.2, 1.3

Fragment Klijent i poslužitelj 7 1.1, 1.2, 1.3

Sve GIOP poruke započinju sa sljedećim zaglavljem, definiranim u IDL-u: module GIOP { // IDL proširen za verzije 1.1, struct Version { // 1.2 i 1.3 octet major; octet minor; }; #ifndef GIOP_1_1 // GIOP 1.0 enum MsgType_1_0 { // preimenovano iz MsgType Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError

18

}; #else // GIOP 1.1 enum MsgType_1_1 { Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment // GIOP 1.1 dodatak }; #endif // GIOP_1_1 // GIOP 1.0 struct MessageHeader_1_0 { // preimenovano iz MessageHeader char magic [4]; // uvijek niz znakova "GIOP" // (ISO 8859-1) Version GIOP_version; boolean byte_order; octet message_type; unsigned long message_size; }; // GIOP 1.1 struct MessageHeader_1_1 { char magic [4]; // uvijek niz znakova "GIOP" // (ISO 8859-1) Version GIOP_version; octet flags; // GIOP 1.1 promjena octet message_type; unsigned long message_size; }; // GIOP 1.2, 1.3 typedef MessageHeader_1_1 MessageHeader_1_2; typedef MessageHeader_1_1 MessageHeader_1_3; };

Slika 3.4: Zaglavlje GIOP poruke

Bitno je izdvojiti polje byte_order (verzija 1.0) i najmanje značajan bit polja flags (verzije 1.1, 1.2, 1.3). Vrijednost false (0) označava big-endian* slijed okteta, dok true (1) označava little-endian** slijed okteta. Ovo pravilo se koristi u pratećim elementima poruke, uključujući i polje message_size.

3.5.3. Prijenos poruka prema protokolu GIOP Protokol GIOP je oblikovan u svrhu implementacije na širokom rasponu prijenosnih protokola. Uzete su u obzir sljedeće pretpostavke:

- Prijenos je spojno orijentiran. GIOP koristi veze za definiranje dosega zahtjeva.

- Prijenos je pouzdan. Specifično, prijenos garantira da su okteti dostavljeni u slijedu u kojem su poslani, najviše jednom, i da je dostupna neka vrsta potvrde prijenosa.

* Najznačajnija vrijednost (bit, oktet) se nalazi na prvom mjestu. ** Najmanje značajna vrijednost (bit, oktet) se nalazi na prvom mjestu.

19

- Prijenos se može promatrati kao tok okteta. Ne postoje ograničenja na veličinu poruke.

- Prijenos pruža određenu razinu obavješćivanja (engl. notification) gubitka veze. Ako jedan od procesa prekine s izvođenjem, računalo padne ili se prekine mrežna povezanost, inicijator veze bi trebao primiti određenu obavijest o statusu ispada.

- Prijenosni model za iniciranje veze može biti mapiran na opći TCP/IP model povezivanja. Specifično, poslužitelj publicira svoju mrežnu adresu unutar interoperabilne reference objekta (engl. Interoperable Object Reference - IOR), koju klijent koristi prilikom iniciranja veze.

Klijent ima mogućnost slanja zahtjeva na više ciljanih objekata koristeći istu vezu, uz uvjet da poslužitelj može odgovoriti na te zahtjeve. Klijent ima odgovornost optimiranja korištenja računalnih sredstava ponovnim korištenjem veza. U protivnom, klijent može otvoriti novu vezu za svaki aktivni objekt podržan poslužiteljem, iako se preporučuje izbjegavati ovaj slučaj.

3.6. Sigurnosna usluga

CORBA sigurnosna usluga definira radno okruženje za korištenje više različitih sigurnosnih tehnologija, kao na primjer Kerberos, DCE sigurnost ili SESAME, za zaštitu CORBA aplikacija. Pruža sučelja koja su dovoljno apstraktna za korištenje bilo koje od navedenih tehnologija. CORBA sigurnosna specifikacija definira sljedeće funkcionalnosti kako bi osigurala sigurnosne mjere protiv mogućih prekršaja:

- Identifikacija i autentifikacija – Dodavanje identiteta principalima (korisnici ili objekti koji imaju potrebu za definiranjem svojeg identiteta) i sposobnost provjere točnosti identiteta principala.

- Autorizacija i kontrola pristupa – Način na koji se odlučuje da li principal ima dozvolu pristupa određenom objektu. Ovo uključuje načine na koje administratori mogu specificirati principale (ili grupe principala) koji mogu pristupiti pojedinim objektima i kako aplikacije mogu odlučiti hoće li dodijeliti dozvolu pristupa principalu.

- Revizija – Vođenje evidencije o tome koji principali obavljaju koje pozive nad zaštićenim objektima. Specifikacija također definira načine odluke o tome koje akcije se prate a koje ne.

- Neporecivost – Stvaranje, prijenos i pohrana nepobitnog dokaza o akciji principala kako bi se kasnije mogao upotrijebiti u slučaju nesuglasica. Ovo može uključivati dokaze o stvaranju objekata i slanju ili primanju poruka.

- Administracija sigurnosne politike – Sučelja koja apliciraju sigurnost na razini domene.

3.6.1. Sigurnosni model Procesi stvaranja zahtjeva, prijenosa zahtjeva preko mreže do ciljnog objekta, izvršavanja operacije i slanja odgovora popraćeni su sigurnosnim procedurama koje osiguravaju primjenu sigurnosnih politika domene. Slika 3.5 prikazuje dvije glavne

20

komponente sigurnosti norme CORBA, kontrolu pristupa i sigurni poziv, te uloge objekata Current i Credentials [6]. Na početku se uspostavlja sigurna veza između klijenta i ciljnog objekta. To znači da mora biti postignuta zadovoljavajuća razina povjerenja između klijenta i ciljnog objekta. Obično klijent pretpostavlja da je dobio pouzdanu referencu objekta, a samo ciljni objekt mora autentificirati identitet klijenta. To se događa tijekom povezivanja klijenta i ciljnog objekta, koje dozvoljava dijeljenje sigurnosnih informacija koje sigurnosna usluga pruža unutar trenutnog konteksta izvođenja. Ovaj kontekst je predstavljen objektom Current, koji pruža operacije i atribute koji dozvoljavaju klijentu i ciljnom objektu postavljanje svojih sigurnosnih atributa i pristup tuđim.

Koristeći objekt Current, ciljni objekt (ili sigurnosna usluga) odlučuje, ovisno o autentificiranom identitetu i privilegijama klijenta (sadržanim u objektu Credentials), o dozvoli izvršavanja zahtijevanog poziva. Ovo se postiže pregledom kontrolnih listi pristupa ili politika koje definiraju grupna članstva, uloge ili slično koje principali moraju posjedovati. Ovu proceduru je moguće izvršiti bez povezivanja s aplikacijom. Ako sigurnosna politika zahtijeva reviziju, odgovarajuće informacije o pozivu moraju se slati posebnim kanalom za reviziju. Ovo se može postići aplikacijom ili automatski sigurnosnom uslugom.

ORB sigurnost ORB sigurnost

ORB jezgra

Kontrola pristupa

Sigurni poziv

Kontrola pristupa

Sigurni poziv

Current

Credentials

Current

Credentials

Ciljni objektKlijent

Povezivanje

LAN/WAN LAN/WAN

Slika 3.5: Sigurnosni model

21

4. Pozivi udaljenih metoda u progamskom okruženju Java

4.1. Uvod

Java RMI (engl. Remote Method Invocation) predstavlja robustan i efikasan način razvoja raspodijeljenih aplikacija u kojem su svi uključeni programi napisani u programskom jeziku Java. Upravo iz razloga što se radi samo u jednom programskom jeziku, RMI predstavlja iznenađujuće jednostavno i lagano radno okruženje. Iako je RMI relativno jednostavan za korištenje, predstavlja osobito moćnu tehnologiju i pruža prosječnom Java razvojnom programeru kompletno novu paradigmu, tj. svijet raspodijeljenih objekata. Primarni cilj RMI dizajnerima bio je dopustiti programerima razvoj raspodijeljenih Java programa s jednakom sintaksom i semantikom korištenom za tradicionalne programe. Kako bi ovo postigli, morali su pažljivo preslikati model Java klasa i objekata u jednostrukom Java virtualnom stroju (engl. Java Virtual Machine - JVM) u novi model klasa i objekata u raspodijeljenom (višestrukom Java virtualnom stroju) okruženju. Budući RMI funkcionira u homogenom okruženju, nema potrebe za korištenjem standardiziranih paradigmi poput jezika IDL.

4.2. Arhitektura RMI

RMI arhitektura bazira se na jednom važnom principu koji odvaja definiciju funkcionalnosti od njene implementacije. RMI dopušta da se izvršni program koji definira funkcionalnost i izvršni program koji je implementira izvršavaju na odvojenim Java virtualnim strojevima. Ovaj princip upravo odgovara potrebama raspodijeljenog sustava gdje su klijenti zaokupljeni definicijom usluga a poslužitelji fokusirani na pružanje istih. Specifično, u RMI-u definicija udaljene usluge ostvarena je korištenjem Java sučelja, dok je implementacija ostvarena u konkretnoj klasi*. RMI sustav izgrađen je od tri apstraktna sloja kao što je prikazano na slici 4.1. Prvi je stub i skeleton sloj, koji predstavlja sučelje prema razvojnom programeru. Ovaj sloj preuzima pozive metoda klijenta nad referencom sučelja i preusmjerava te pozive na udaljenu RMI uslugu. Sljedeći sloj je udaljena referenca, koji razumije kako interpretirati i upravljati referencama klijenata prema objektima udaljene usluge. Prijenosni sloj zasnovan je na TCP/IP vezama između računala na mreži. Pruža osnovnu povezivost, kao i pojedine strategije zaobilaženja sigurnosne stijene. Korištenjem slojevite arhitekture, svakog od slojeva moguće je poboljšati ili zamijeniti bez ikakvih učinaka na ostatak sustava.

* Klasa koju je moguće instancirati. Suprotno od apstraktne klase.

22

Slika 4.1: Java RMI arhitektura

4.2.1. Stub/skeleton sloj Kada klijent započinje s pozivom metode poslužitelja na udaljenom računalu, sučelje, odnosno API (engl. Application Programming Interface), koje se koristi je predstavljeno stub/skeleton izvršnim programom. Nasljeđivanjem određenih RMI klasa, objekt poprima nekoliko RMI metoda koje je potrebno ostvariti. U ovom sloju, RMI koristi model oblikovanja temeljen na zamjenskom objektu (engl. proxy design pattern) u kojem je objekt, u jednom kontekstu, predstavljen drugim (zamjenskim) objektom, u odvojenom kontekstu. Zamjenski objekt zna kako prosljeđivati pozive metoda između participirajućih objekata. Kod RMI-a, stub klasa igra ulogu zamjenskog objekta. Skeleton je pomoćna klasa generirana za korištenje od strane okruženja RMI. Skeleton razumije kako komunicirati sa stub-om preko RMI veze, odnosno čita parametre poziva metode iz veze, izvršava poziv nad implementacijom objekta udaljene usluge, prima povratnu vrijednost te je vraća stub-u. U Java 2 SDK implementaciji okruženja RMI, novi protokol na "žici" (engl. wire protocol) je učinio skeleton klase zastarjelima te koristi refleksiju* za spajanje na objekt udaljene usluge.

4.2.2. Sloj udaljene reference Sloj udaljene reference definira i podržava semantiku poziva RMI veze. Ovaj sloj osigurava objekt RemoteRef koji predstavlja vezu s implementiranim objektom udaljene usluge. Stub objekti koriste metodu invoke() objekta RemoteRef za prosljeđivanje poziva metode.

* Svojstvo koje omogućava aplikaciji pristup svojim meta podacima, poput opisa ostvarenih metoda.

23

JDK 1.1 implementacija RMI-a osigurava samo jedan način spajanja klijenata na ostvarenja udaljenih usluga, tj. unicast način, odnosno vezu točka-točka (engl. point-to-point). Prije nego što klijent može koristiti udaljenu uslugu, ona mora biti instancirana na poslužitelju i publicirana u RMI sustavu. Java 2 SDK implementacija RMI-a dodaje novu semantiku vezi klijent/poslužitelj. U ovoj verziji, RMI podržava aktivirajuće udaljene objekte. Kada je poziv metode aktivirajućeg objekta izvršen nad zamjenskim objektom, RMI prvo doznaje da li je implementacija objekta udaljene usluge aktivna ili ne. Ako nije, RMI će instancirati objekt i vratiti mu zadnje stanje koje je potencijalno pohranjeno u datoteci na disku. U trenutku kada je aktivirajući objekt u spremniku, ponaša se identično JDK 1.1 implementacijama objekata udaljenih usluga. Druge vrste semantike veze su također moguće. Na primjer, u multicast načinu, jedan zamjenski objekt može poslati zahtjev za metodom istovremeno na više implementacija i prihvatiti prvi odgovor, što skraćuje vrijeme odziva i unaprjeđuje dostupnost.

4.2.3. Prijenosni sloj Prijenosni sloj RMI sustava odgovoran je za uspostavljanje veza s udaljenim adresnim prostorima, upravljanje vezama, nadgledanje stanja veza, slušanje na dolazeće pozive, održavanje tablice udaljenih objekata koji se nalaze u adresnom prostoru, uspostavljanje veza za dolazeći poziv i pronalaženje usmjerivača za cilj udaljenog poziva i prosljeđivanje zahtjeva tom usmjerivaču. Konkretna reprezentacija reference udaljenog objekta sastoji se od krajnje točke i identifikatora objekta. Ova reprezentacija se naziva živa referenca. S postojećom živom referencom udaljenog objekta, prijenosni sloj može koristiti krajnju točku za uspostavljanje veze s adresnim prostorom udaljenog objekta. Na strani poslužitelja, prijenosni sloj koristi identifikator objekta za pronalaženje cilja udaljenog poziva. Sve veze su tokovno orijentirane mrežne veze koje koriste TCP/IP protokol. Povrh TCP/IP protokola, RMI koristi protokol Java Remote Method Protocol (JRMP) na razini "žice". JRMP je vlasnički, tokovno orijentiran protokol koji je samo djelomično specificiran i postoji u dvije verzije; prva koja koristi skeleton klase na poslužitelju i druga koja ih ne koristi.

4.3. Sakupljanje smeća

Jedna od najvećih prednosti programskog jezika Java je nepostojanje kazaljki. Nema potrebe za oslobađanjem spremničkog prostora, niti za brigom oko načina pohranjivanja u spremnik. Ovo je preduvjet platformskoj nezavisnosti jer je u suprotnom potrebno voditi računa o načinima upravljanja spremnikom za svaku posebnu arhitekturu. Java RMI nije nikakva iznimka ovog pravila. Štoviše, sadrži složeni postupak sakupljanja smeća (engl. garbage collection) zasnovan na konceptu brojila referenci objekta preuzetim iz programskog jezika Modula-3. RMI pohranjuje brojilo referenci objekta unutar svakog objekta. Svaki puta kada drugi objekt komunicira s udaljenim objektom, brojilo referenci objekta je uvećano za jedan, dok u trenutku kada objekt više ne treba udaljeni objekt brojilo se smanjuje za jedan.

24

Postoje mnogo zaštitnih slojeva oko algoritma sakupljanja smeća koji sprječavaju prijevremeno oslobađanje objekta. Veći dio posla RMI raspodijeljenog sakupljanja smeća obavlja algoritam sakupljanja smeća lokalnog Java virtualnog stroja. Na primjer, kada lokalni objekt započne komunikaciju s udaljenim objektom, komunikacija teče slojevima RMI sustava. Lokalni objekt stvori mrežni objekt kao dio sloja udaljene reference. Na drugoj strani, sloj udaljene reference stvori još jedan mrežni objekt koji komunicira s udaljenim objektom. Na ovaj način, udaljeni JVM uvidi da udaljeni objekt ne smije biti oslobođen i zadrži algoritam sakupljanja smeća čitavo vrijeme dok udaljeni mrežni objekt poziva njegove metode. Slika 4.2 ilustrira navedeni princip.

Slika 4.2: Utjecaj mrežnih objekata na raspodijeljeno sakupljanje smeća

Na lokalnom računalu, kada se udaljeni objekt više ne koristi, sloj udaljene reference ukloni sve reference na lokalni mrežni objekt. Slijedi oslobađanje navedenog objekta čija rutina finalize pošalje poruku udaljenom mrežnom objektu kroz sloj udaljene reference, kako bi taj oslobodio referencu na udaljeni objekt. Ako više niti jedan klijent ne referencira udaljeni objekt, RMI izvršno okruženje ga označava sa slabom referencom koja dopušta algoritmu sakupljanja smeća njegovo oslobađanje.

4.4. Protokol JRMP

Format protokola na "žici" tehnike RMI predstavljen je tokom podataka. Ulazni i izlazni tokovi korišteni od strane okruženja RMI, koji se odnose na klijenta, su međusobno upareni. Svaki izlazni tok ima odgovarajući ulazni tok, te zbog toga

25

jedina potrebna informacija u zaglavlju ulaznog toka je potvrda o raspoznavanju protokola [44].

4.4.1. Format izlaznog toka Izlazni tok u okruženju RMI sastoji se od prijenosnog zaglavlja iza kojeg slijedi niz poruka. Alternativno, izlazni tok može sadržavati poziv smješten unutar HTTP protokola. U nastavku je navedena gramatika izlaznog toka.

Out: Header Messages HttpMessage

Header: 0x4a 0x52 0x4d 0x49 Version Protocol

Version: 0x00 0x01

Protocol: StreamProtocol SingleOpProtocol MultiplexProtocol

StreamProtocol: 0x4b

SingleOpProtocol: 0x4c

MultiplexProtocol: 0x4d

Messages: Message Messages Message

Slika 4.3: Format izlaznog toka

Poruke su omotane unutar određenog protokola specificiranim elementom Protocol. U slučaju protokola SingleOpProtocol moguća je samo jedna poruka nakon zaglavlja i ne postoje dodatni podaci u koje je poruka omotana. Protokol SingleOpProtocol se koristi za poziv smješten unutar HTTP zahtjeva gdje nije moguća interakcija izvan konteksta jednog zahtjeva i odgovora.

Za protokole StreamProtocol i MultiplexProtocol, poslužitelj mora odgovoriti s oktetom 0x4e potvrđujući podršku za navedeni protokol i s identifikatorom EndpointIdentifier koji sadrži naziv računala i broj pristupa koje poslužitelj vidi na strani klijenta. Klijent može koristiti ovu informaciju za određivanje svojeg naziva računala ako je u nemogućnosti do toga doći na drugi način iz sigurnosnih razloga. Tada klijent mora odgovoriti s još jednim identifikatorom EndpointIdentifier koji sadrži unaprijed postavljenu krajnju točku klijenta za prihvaćanje veza. Taj identifikator može koristiti poslužitelj u slučaju protokola MultiplexProtocol kako bi identificirao klijenta.

U protokolu StreamProtocol, nakon dogovora o krajnjoj točki, poruke se šalju izlaznim tokom bez dodatnog omatanja podataka. Za protokol MultiplexProtocol, jedna TCP/IP veza se koristi za više logičkih veza.

26

Postoje tri vrste izlaznih poruka: Call, Ping i DgcAck. Poruka Call kodira poziv metode, Ping predstavlja poruku prijenosnog nivoa za testiranje stanja udaljenog Java virtualnog stroja, dok je DgcAck potvrda usmjerena raspodijeljenom sakupljaču smeća poslužitelja koja pokazuje da su udaljeni objekti u povratnoj vrijednosti poslužitelja primljeni od strane klijenta. Na slici 4.4 je prikazana gramatika izlaznih poruka.

Message: Call Ping DgcAck

Call: 0x50 CallData

Ping: 0x52

DgcAck: 0x54 UniqueIdentifier

Slika 4.4: Format izlazne poruke

4.4.2. Format ulaznog toka Zasad postoje tri vrste ulaznih poruka: ReturnData, HttpReturn i PingAck. Poruka ReturnData je rezultat normalnog poziva udaljene metode, HttpReturn je rezultat poziva smješten unutar HTTP protokola, dok je PingAck potvrda Ping poruke. Na slici 4.5 je prikazana gramatika ulaznog toka.

In: ProtocolAck Returns ProtocolNotSupported HttpReturn

ProtocolAck: 0x4e

ProtocolNotSupported: 0x4f

Returns: Return Returns Return

Return: ReturnData PingAck

ReturnData: 0x51 ReturnValue

PingAck: 0x53

Slika 4.5: Format ulaznog toka

27

4.4.3. Serijalizacija objekta Podaci poziva i odgovora u porukama okruženja RMI formatirani su korištenjem protokola Java objektne serijalizacije*. Sadržaj svakog poziva metode (CallData) zapisuje se u Java izlazni tok objekta koji sadrži cilj poziva (ObjectIdentifier), broj koji označava metodu koja se poziva (Operation), broj koji potvrđuje da stub klijenta i skeleton udaljenog objekta koriste isti stub protokol (Hash) i niz od nula ili više argumenata poziva (Arguments). Navedeno je prikazano na slici 4.6.

CallData: ObjectIdentifier Operation Hash Argumentsopt

ObjectIdentifier: ObjectNumber UniqueIdentifier

UniqueIdentifier: Number Time Count

Arguments: Value Arguments Value

Value: Object Primitive

Slika 4.6: Format Java objektne serijalizacije

Povratna vrijednost ReturnValue poziva udaljene metode sastoji se od povratnog koda koji identificira normalni status izvođenja ili iznimku, identifikatora UniqueIdentifier za identifikaciju povratne vrijednosti (koja se koristi u slanju poruke DgcAck, ako je to potrebno) i rezultata poziva koji može biti povratna vrijednost Value ili iznimka Exception.

ReturnValue: 0x01 UniqueIdentifier Valueopt 0x02 UniqueIdentifier Exception

Slika 4.7: Format povratne vrijednosti

4.4.4. Korištenje protokola HTTP POST Kako bi se pozvale udaljene metode unatoč zaštiti sigurnosnom stijenom, poneki pozivi udaljenih metoda koriste HTTP protokol, odnosno HTTP POST protokol. URL specificiran u zaglavlju poruke može imati jedan od sljedećih oblika:

http://<host>:<port>/ http://<host>:80/cgi-bin/java-rmi?forward=<port>

Prva adresa (URL) se koristi za izravnu komunikaciju s RMI poslužiteljem na određenom računalu (host) i pristupu (port), dok se oblik drugog URL-a koristi za poziv cgi skripte na Web poslužitelju koja prosljeđuje poziv RMI poslužitelju na određenom pristupu (port). Slika 4.8 prikazuje format RMI poruke omotane u HTTP POST protokol. Element HttpPostHeader predstavlja standardno HTTP zaglavlje za zahtjev POST, dok je element HttpResponseHeader standardno zaglavlje HTTP odgovora. Ako statusni kod * Konverzija instance objekta u niz okteta prikladan za prijenos preko mreže.

28

odgovora nije 200, tada se pretpostavlja da nema povratne vrijednosti Return. Treba napomenuti da je unutar HTTP POST zahtjeva sadržan samo jedan poziv udaljene metode.

HttpMessage: HttpPostHeader Header Message

HttpReturn: HttpResponseHeader Return

Slika 4.8: Format RMI poruke unutar HTTP POST omotnice

4.5. Sigurnost u Java okruženju

4.5.1. Vrste sigurnosnih dozvola Java 2 sadrži novi sigurnosni model u odnosu na stariju verziju. Učinak ovog novog modela je da izvršnom programu nije dopušten pristup bilo čemu što nije u potpunosti sadržano u Java virtualnom stroju, dakako s iznimkom ako je prethodno eksplicitno dobio dozvolu. Na primjer, stara aplikacija, koja nema odgovarajuće dozvole, više neće moći otvarati pristupne točke. Kako sve RMI poruke putuju preko pristupnih točki, novi sigurnosni model dosta ometa izvršavanje starih aplikacija. Java 2 uvodi mogućnost definiranja tzv. korisničkog sandbox-a*, što se postiže listom dozvola koje se moraju dodijeliti dijelovima izvršnog programa. Prema unaprijed postavljenim vrijednostima, cijela aplikacija se izvršava unutar najštićenijeg i najviše ograničenog sandbox-a. Sandbox može biti selektivno konfiguriran dodjeljivanjem dozvola dijelovima izvršnog programa kako bi se izvodile određene akcije, kao što je otvaranje pristupne točke na određenom pristupu. Također, treba napomenuti da se dozvole ne dodjeljuju čitavoj aplikaciji već klasama unutar aplikacije. Glavni razlog tome je mogućnost dinamičkog učitavanja klasa. U Java 2 okruženju postoji devet vrsta sigurnosnih dozvola [8]:

- Kontrola pristupa prozorima (AWT dozvole) - Kontrola pristupa datotekama (File dozvole) - Kontrola pristupa mreži (Network dozvole) - Kontrola pristupa pristupnim točkama (Socket dozvole) - Kontrola pristupa svojstvima (Property dozvole) - Kontrola pristupa refleksiji (Reflection dozvole) - Kontrola pristupa izvršnom okruženju (Runtime dozvole) - Kontrola pristupa sigurnosnim mehanizmima (Security dozvole) - Kontrola pristupa serijalizaciji (Serializable dozvole)

Svaka od ovih vrsta dozvola definira specifični način na koji se sandbox može probiti. Za tipičnu RMI aplikaciju, četiri najvažnije vrste su AWT dozvole, file dozvole, socket dozvole i property dozvole i o njima će biti riječi u nastavku. * Sigurnosna mjera u Java okruženju koja predstavlja skup sigurnosnih pravila korištenih prilikom izvođenja aplikacije (uglavnom se odnosi na applet-e).

29

Kontrola pristupa prozorima kontrolira pristup računalnim sredstvima vezanim uz prozore. Ova vrsta dozvole je stvorena kao odgovor na tri moguće sigurnosne rupe:

- Zavaravanje korisnika – Neprijateljski kod se može pretvarati da je prijateljski. Na primjer, može otvoriti niz prozora "čarobnjaka za registraciju" te na taj način doći do osobnih podataka.

- Skupljanje statičkih informacija – Alternativno, neprijateljski kod može jednostavno pogledati u međuspremnik (engl. clipboard) ili uhvatiti ono što se nalazi na ekranu.

- Zavaravanje izvođene aplikacije – Treća sigurnosna rupa uključuje oponašanje korisnika. Java 2 sadrži novi mehanizam, nazvan robot, koji simulira korisničke akcije. Iako je primarno namijenjen za automatizirano testiranje korisničkog sučelja, događaji generirani preko mehanizma robota ne razlikuju se od stvarnih korisničkih akcija.

Budući se radi o različitim sigurnosnim rupama, postoji šest podvrsta AWT dozvole: accessClipBoard, accessEventQueue, listenToAllAwtEvents, readDisplayPixels, showWindowWithoutWarningBanner i createRobot. Sve su boolean vrijednosti, što znači da dio izvršnog programa ili ima dozvolu za izvršavanje određene operacije ili je nema. Slijedi primjer dozvole koja dozvoljava svim klasama mogućnost prikazivanja prozora bez upozoravajućih banera.

grant { permission java.awt.AWTPermission "showWindowWithoutWarningBanner"; };

Slika 4.9: Primjer AWT dozvole

Kontrola pristupa datotekama jednostavno kontrolira izvođenje operacija nad datotekama. Postoje četiri osnovne datotečne operacije: čitanje, pisanje, izvođenje i brisanje. Primjereno tome, postoje četiri vrste file dozvola: read, write, execute i delete. Slijedi primjer dozvole koja dozvoljava svim klasama čitanje, pisanje i brisanje, ali ne i izvođenje svih datoteka u direktoriju C:\temp\ i njegovim poddirektorijima.

grant { permission java.io.FilePermission "C:/temp/-" , "read, write, delete"; };

Slika 4.10: Primjer file dozvole

Kontrola pristupa pristupnim točkama predstavlja kontrolu nad operacijama vezanim uz pristupne točke. Postoje četiri osnovne socket dozvole: razlučivanje adrese, spajanje, osluškivanje veza i prihvaćanje veza. Povezane s ove četiri operacije su četiri socket dozvole: resolve, connect, listen i accept. Razlika između dozvole listen i dozvole accept je donekle neobična. Dok dozvola listen specificira na kojim pristupima pristupna točka poslužitelja ima dozvolu za osluškivanje, dozvola accept specificira od koga pristupna točka poslužitelja ima dozvolu prihvatiti veze. Također, iako se dozvole resolve i listen mogu dodjeljivati, to se rijetko čini budući je dozvola resolve podrazumijevana bilo kojom drugom operacijom, a dozvola listen dozvolom accept.

30

Slijedi primjer dozvole koja dozvoljava klasama prihvaćanje veza s bilo kojim računalom unutar domene *.mojadomena.com, na svakom pristupu većem od 1024.

grant { permission java.net.SocketPermission "*.mojadomena.com:1024-", "accept, connect"; };

Slika 4.11: Primjer socket dozvole

Posljednja vrsta kontrole o kojoj će biti riječi je kontrola pristupa svojstvima. Klasa System, definirana u paketu java.lang, ima statičku referencu na singleton* objekt svojstva koji se može dohvatiti pozivom metode System.getProperties(). Ovaj objekt svojstva predstavlja instancu klase java.util.Properties, te sadrži skup kanoničkih parova ime-vrijednost koji specificiraju informacije o Java virtualnom stroju i svim svojstvima komandne linije postavljenim sa –D zastavicom. Prema unaprijed postavljenim postavkama, klasa ne može čitati ili postavljati svojstva sustava. Međutim, property dozvole read i write se koriste za uklanjanje takvih ograničenja. U nastavku su navedene tipične property dozvole koje dodjeljuju svakoj klasi sposobnost čitanja ali ne i mijenjanja određenih kanoničkih svojstva.

grant { permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; }

Slika 4.12: Primjer property dozvole

4.5.2. Sigurnosni upravitelj Unutar Java virtualnog stroja, dozvole su nametnute instancom klase SecurityManager, koja predstavlja sigurnosnog upravitelja. Kada program pokuša izvršiti operaciju koja zahtjeva dozvolu, instanca klase SecurityManager je upitana o uspješnosti izvođenja operacije. Tako, na primjer, pokušaj čitanja podataka iz datoteke uključuje upit nad sigurnosnim upraviteljem o dozvoli programa za navedenu operaciju. Za opis automatskog instanciranja sigurnosnog upravitelja poslužit će nam klasa Socket čiji konstruktor započinje segmentom izvornog teksta koji poziva instaliranog sigurnosnog upravitelja i provjerava dopuštenost veze, a prikazan je na slici 4.13.

private Socket(InetAddress address, int port, InetAddress localAddr, int localPort, boolean stream) throws IOException { this(); if (port < 0 || port > 0xFFFF) { throw new IllegalArgumentException("pristup je izvan "+ "granica: "+port); } if (localPort < 0 || localPort > 0xFFFF) {

* Vrsta klase koja ima samo jednu, globalna instancu unutar određenog procesa.

31

throw new IllegalArgumentException("pristup je izvan "+ "granica: "+localPort); } SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkConnect(address.getHostAddress(), port); } .... }

Slika 4.13: Automatsko instanciranje sigurnosnog upravitelja

Važno je napomenuti da u slučaju ako ne postoji instalirana instanca klase SecurityManager niti jedna od navedenih provjera se neće izvesti. Ovo predstavlja opći model koji definira što se zbiva ako sigurnosni upravitelj nije instaliran. U tom slučaju nema provjera dozvola, a aplikacija ima dozvolu za izvršavanje svih operacija. Ovo je potrebno za kompatibilnost unatrag, ali u isto vrijeme čini kompletno radno okruženje više naklonjeno sigurnosnim propustima. Postoje dva načina instaliranja sigurnosnog upravitelja: kroz komandnu liniju definiranjem svojstva sustava ili pozivom metode System.setSecurityManager() unutar samog izvornog teksta programa. Obično se kod RMI aplikacija koristi drugi način jer dinamičko učitavanje klasa zahtjeva instaliranu instancu sigurnosnog upravitelja. Okruženje RMI pruža jednostavnog sigurnosnog upravitelja, nazvanog RMISecurityManager, u paketu java.rmi. U Java 2, klasa RMISecurityManager jednostavno nasljeđuje standardnog sigurnosnog upravitelja bez dodatnih funkcionalnosti. Većina RMI aplikacija koristi sigurnosnog upravitelja RMISecurityManager zbog bolje dokumentacije i automatske evolucije izvršnog programa u slučaju kada sigurnosni model okruženja RMI postane razrađeniji.

4.5.3. Datoteke sigurnosne politike Postoje tri vrste datoteka sigurnosne politike koje koristi sigurnosni upravitelj:

- Globalna datoteka politike – Odnosi se na sve aplikacije i sve korisnike. Obično je to unaprijed definirana politika Java izvršnog okruženja ili datoteka politike definirana od strane administratora sustava. Prema unaprijed postavljenim postavkama instalirana je u direktorij %java_home%\jre\lib\security\java.policy.

- Korisnička datoteka politike – Primjenjuje se na sve aplikacije koje pokreće korisnik. Obično ne postoji ili ju definira administrator sustava.

- Aplikacijska datoteka politike – Dostavlja se zajedno s aplikacijom te definira dozvole koje aplikacija zahtjeva kako bi se ispravno izvodila.

Datoteka politike se sastoji od niza grant naredbi. Svaka naredba grant ima sljedeći oblik:

grant [signedBy Ime] [codeBase URL] { // lista dozvola };

Slika 4.14: Struktura datoteke politike

Ovo se prevodi u sljedeću rečenicu:

32

Svaka klasa učitana s lokacije definirane parametrom URL i digitalno potpisana parametrom Ime ima dozvole zapisane u listi dozvola.

4.5.4. Java usluga autentifikacije i autorizacije Java usluga autentifikacije i autorizacije (engl. Java Authentication and Authorization Service – JAAS) je sastavni dio Java 2 programskog okruženja (od verzije 1.4) i može se koristiti u sljedeće dvije svrhe [47]:

- Za autentifikaciju korisnika – Moguće je pouzdano znati tko trenutno izvodi Java program, bez obzira da li se program izvodi kao aplikacija, applet, bean ili servlet.

- Za autorizaciju korisnika – Osiguravanje da korisnici imaju dozvole potrebne za izvršavanje željenih radnji.

Usluga JAAS ostvaruje Java verziju normiranog radnog okruženja Pluggable Authentication Module (PAM). Radno okruženje PAM pruža mogućnost povezivanja više mehanizama autentifikacije s postojećim sustavom putem specifičnih modula. Za razliku od tradicionalne sigurnosne politike Java 2 okruženja, koja pruža kontrolu pristupa računalnim sredstvima temeljenu na izvorišnoj lokaciji izvršavanog programa i njegovom digitalnom potpisu, usluga JAAS pruža radno okruženje koje nadopunjuje arhitekturu sigurnosti Java 2 okruženja s kontrolom pristupa zasnovanom na subjektu koji izvršava program. Kako je usluga JAAS ostvarenje radnog okruženja PAM, tako JAAS autentifikacija omogućuje aplikacijama da budu neovisne o korištenim autentifikacijskim tehnologijama. Nove ili nadopunjene autentifikacijske tehnologije mogu postati sastavni dio aplikacije bez potreba za promjenama u samoj aplikaciji. Aplikacije aktiviraju autentifikacijski proces instanciranjem objekta klase LoginContext, koji referencira objekt klase Configuration kako bi odredio korištene autentifikacijske tehnologije. Pojedina autentifikacijska tehnologija je predstavljena implementacijom sučelja LoginModule. Tipične implementacije sučelja LoginModule od korisnika preuzimaju korisničko ime i lozinku, dok druge mogu učitati i verificirati, na primjer, otisak prsta. Nakon što je korisnik, koji izvršava program, autentificiran, komponenta JAAS autorizacije djeluje u suradnji s temeljnim modelom kontrole pristupa Java 2 okruženja s ciljem zaštite osjetljivih sredstava. Korisnik, koji izvršava program, je predstavljen objektom klase Subject, kojeg objekt LoginModule ažurira s odgovarajućim identitetima, predstavljenim implementacijama sučelja Principal, i akreditacijama (engl. credentials) koje mogu biti predstavljene bilo kojim objektom.

Autentifikacijske tehnologije, odnosno objekti klase LoginContext, koje se koriste u aplikaciji se navode u konfiguracijskoj datoteci. Sadržaj ove datoteke učitava objekt klase Configuration, a njezin primjer je prikazan na slici 4.15.

JRMIIRCClient { com.sun.security.auth.module.NTLoginModule sufficient; };

Slika 4.15: Konfiguracija za korištenje Windows NT autentifikacije

U svrhu autorizacije, usluga JAAS proširuje naredbu grant koja predstavlja temeljno sredstvo određivanja sigurnosne politike aplikacije. Proširenje se sastoji od polja

33

Principal koje definira korisnika na kojeg se dozvole odnose. Prošireni oblik naredbe grant je prikazan na slici 4.16.

grant [signedBy Ime] [codeBase URL] [Principal klasa_principala "ime_principala"] { permission naziv_klase_dozvole "naziv_cilja", "dozvola"; .... permission naziv_klase_dozvole "naziv_cilja", "dozvola"; };

Slika 4.16: Prošireni oblik naredbe grant

Tehnika RMI ne implementira proces same razmjene sigurnosnih informacija u korist autentifikacije i autorizacije korisnika. Stoga, taj proces mora biti rješen korisnički.

34

5. Arhitektura zasnovana na Microsoftovom modelu DCOM

5.1. Uvod

Arhitektura zasnovana na Microsoftovom modelu DCOM (Distributed COM) proširuje komponentni objektni model (engl. Component Object Model - COM) kako bi podržao komunikaciju između objekata na različitim računalima povezanim u računalnu mrežu. Kako DCOM prema programeru predstavlja neprimjetnu evolucija okruženja COM, moguće je iskoristiti postojeće ulaganje u COM-bazirane aplikacije, komponente, alate i znanje za pomak u svijet raspodijeljenog računarstva koji se oslanja na norme. DCOM je mrežni protokol visoke razine koji od programera preuzima posao pisanja izvornog teksta programa za upravljanje komunikacijom potrebnom za interakciju raspodijeljenih komponenti preko mreže. DCOM nije programski jezik, već specifikacija i usluga izgrađena pomoću COM-a, te koristi COM objektno orijentiranu tehnologiju za pružanje svojih usluga. Izdavanjem DCOM-a, Microsoft je uveo novi skup sučelja niske razine za pozive udaljenih metoda nazvan Object Remote Procedure Call (ORPC). Protokol ORPC se nalazi povrh normiranog okruženja za poziv udaljenih procedura Distributed Computing Environment RPC (DCE RPC), te proširuje model proceduralnog programiranja u svrhu podržavanja raspodijeljenih objekata.

5.2. Arhitektura DCOM

U današnjim operacijskim sustavima procesi su zaštićeni jedan od drugoga. Klijent koji treba komunicirati s komponentom u drugom procesu ne može pozvati komponentu direktno već mora koristiti neki oblik među-procesne komunikacije koju omogućuje operacijski sustav. COM pruža ovu komunikaciju u kompletno transparentnom obliku, tj. preuzima pozive od klijenta i prosljeđuje ih komponenti u drugom procesu. Slika 5.1 pokazuje kako COM/DCOM biblioteke izvršnog okruženja pružaju vezu između klijenta i komponente unutar istog računala.

Slika 5.1: COM komponente u različitim procesima

35

Kada se klijent i komponenta nalaze na različitim računalima, DCOM jednostavno zamijeni lokalnu među-procesnu komunikaciju s mrežnim protokolom. Niti klijent niti komponenta nisu svjesni da se komunikacijski put zapravo produžio. Slika 5.2 prikazuje cjelokupnu DCOM arhitekturu. COM izvršno okruženje pruža objektno-orijentirane usluge klijentima i komponentama i koristi RPC i pružatelja sigurnosti za generiranje mrežnih paketa koji odgovaraju normi DCOM protokola na "žici".

Klijent

Slog protokola

Pružateljsigurnosti DCE RPC

DCOM mrežni protokol

Proxy objekt

ServiceControl

Manager

COM objekt Stub objekt

Slog protokola

Pružateljsigurnosti DCE RPC

ServiceControl

Manager

Slika 5.2: DCOM – COM komponente na različitim računalima

Kao i sva COM komunikacija, poziv udaljene metode započinje kada klijent zatraži sučelje od poslužitelja. U DCOM-u, klijent poziva metodu CoCreateInstanceEx(), s argumentima koji predstavljaju opis računala poslužitelja, te identifikacije klase i sučelja zahtjevanog COM objekta (CLSID). Zahtjev obrađuje upravitelj kontrole usluga (engl. Service Control Manager - SCM), koji je dio operacijskog sustava Windows. Upravitelj kontrole usluga je odgovoran za stvaranje i aktivaciju COM objekata na računalu poslužitelja. U slučaju DCOM-a, upravitelj SCM će pokušati stvoriti objekt na udaljenom računalu. Kada se poslužitelj nalazi unutar procesa klijenta, kazaljke u virtualnoj tablici (VTABLE) pokazuju na metode koje su smještene u istom adresnom prostoru. Međutim, kazaljke mogu pristupiti jedino informacijama unutar adresnog prostora procesa, što znači da ako je poslužitelj izvan procesa klijenta, kazaljke sučelja klijenta nemaju dozvolu pristupa informacijama u adresnom prostoru procesa poslužitelja. Kako bi riješio ovaj problem, COM se oslanja na specijalni dio programske opreme unutar procesa klijenta, nazvan zamjenski objekt (engl. proxy object). Kada klijent primi kazaljku na sučelje objekta izvan procesa, on je u stvari primio kazaljku na zamjenski objekt. Zamjenski objekt postoji kako bi preuzeo mjesto udaljenog objekta i prosljeđivao sve zahtjeve klijenta drugom specijalnom djelu programske opreme poznatom pod nazivom stub. Budući se zamjenski objekt nalazi unutar procesa klijenta, kazaljka sučelja klijenta mu može pristupiti. Prema klijentu, zamjenski objekt se čini kao ciljni objekt. Zamjenski objekt je također odgovoran za pakiranje bilo kojih parametara potrebnih za pozivanje određene metode, odnosno proces pod nazivom marshaling.

36

Kao i zamjenski objekt, stub je također unutar procesa, i to unutar adresnog prostora procesa poslužitelja. Stub prima zahtjeve od zamjenskog objekta i raspakira sve parametre prije stvarnog poziva metode sučelja. Sa stajališta ciljnog objekta, stub je klijent. Objekt, odnosno COM poslužitelj, šalje povratne podatke stub-u koji ih prosljeđuje zamjenskom objektu, a koji ih na kraju šalje klijentu. Čitav ovaj proces se odvija u pozadini, bez znanja klijenta i poslužitelja. Kada klijent pristupa lokalnom poslužitelju, odnosno poslužitelju koji se nalazi na istom računalu ali u drugom procesu, zamjenski objekt i stub komuniciraju pomoću mehanizma lokalnog poziva procedure (engl. Local Procedure Call - LPC). Mehanizam LPC predstavlja oblik među-procesne komunikacije specifično dizajnirane za poziv metoda u drugom procesu. LPC funkcionira samo u slučaju kad su zamjenski objekt i stub smješteni na istom računalu. Međutim, kada su smješteni na različitim računalima, komuniciraju pomoću protokola ORPC. Protokol ORPC može funkcionirati povrh više protokola, uključujući TCP/IP, UDP, NetBEUI, NetBIOS i imenovane cjevovode. Standardni protokol povrh kojeg ORPC funkcionira je UDP (engl. User Datagram Protocol), koji je bespojni protokol, međutim ovo ne predstavlja problem jer se ORPC automatski brine o vezama.

5.3. Pakiranje parametara

5.3.1. Vrste pakiranja parametara Klijent pakira i raspakira parametre korištenjem zamjenskog objekta. Ovaj objekt pruža ista sučelja kao i COM poslužitelj. Umjesto implementiranja metoda COM poslužitelja, zamjenski objekt jednostavno pakira parametre metode te ih šalje stub objektu COM poslužitelja. Postoje tri vrste pakiranja parametara: pakiranje parametara pomoću biblioteke tipova, standardno pakiranje parametara i korisničko pakiranje parametara [9].

5.3.2. Pakiranje parametara pomoću biblioteke tipova Pakiranje parametara pomoću biblioteke tipova koristi prednost činjenice da svaka instalacija okruženja COM već ima instaliranu podršku za automatsko pakiranje parametara. Jedini nedostatak je limitiran skup podatkovnih tipova koji su podržani automatskim pakiranjem. Umjesto instaliranja korisničkog proxy/stub modula na strani klijenta i poslužitelja, koristi se proxy/stub par kojeg koristi podrška za automatsko pakiranje parametara. Kako bi ovo bilo omogućeno, potrebno je instalirati biblioteku tipova na računalo klijenta i poslužitelja. Također, kako bi sustav znao da treba koristiti ovu vrstu pakiranja parametara, potrebno je u registar (engl. registry) dodati specijalni indikator koji pokazuje da se koristi podrška za automatsko pakiranje parametara i informaciju o smještaju biblioteke tipova.

5.3.3. Standardno pakiranje parametara Standardno pakiranje parametara postiže se korištenjem jezičnog procesora Microsoft-ovog jezika za definiciju sučelja (MIDL). Pod pretpostavkom da postoji sučelje IMyInterface spremljeno u datoteci myinterface.idl, MIDL jezični procesor

37

se može koristiti za generiranje proxy/stub izvornog teksta programa za sučelje. Izlaz MIDL jezičnog procesora sastoji se od pet datoteka:

- myinterface.h – Datoteka zaglavlja s definicijom sučelja.

- myinterface_i.c – Datoteka izvornog teksta programa s definicijom IID (engl. Interface ID) konstanti.

- myinterface_p.c – Datoteka izvornog teksta programa proxy/stub para.

- dlldata.c – Datoteka izvornog teksta programa s proxy/stub DLL ulaznim točkama.

- myinterface.tlb – Biblioteka tipova koja se može koristiti u pakiranju parametara pomoću biblioteke tipova.

5.3.4. Korisničko pakiranje parametara Općenito, prihvatljivo je koristiti standardno pakiranje parametara. Međutim, može se pojaviti potreba za učinkovitijim korisničkim pakiranjem parametara. Neki objekt može implementirati korisničko pakiranje parametara izlaganjem sučelja IMarshal. U nastavku je navedena definicija IMarshal sučelja u jeziku MIDL [9].

interface IMarshal : IUnknown { HRESULT GetUnmarshalClass([in] REFIID riid, [in, unique] void * pv, [in] DWORD dwDestContext, [in, unique] void * pvDestContext, [in] DWORD mshlflags, [out] CLSID * pCid); HRESULT GetMarshalSizeMax([in] REFIID riid, [in, unique] void * pv, [in] DWORD dwDestContext, [in, unique] void * pvDestContext, [in] DWORD mshlflags, [out] DWORD * pSize); HRESULT MarshalInterface([in, unique] IStream * pStm, [in] REFIID riid, [in, unique] void * pv, [in] DWORD dwDestContext, [in, unique] void * pvDestContext, [in] DWORD mshlflags); HRSEULT UnmarshalInterface([in, unique] IStream * pStm, [in] REFIID riid, [out] void ** ppv); HRESULT ReleaseMarshalData([in, unique] IStream * pStm); HRESULT DisconnectObject([in] DWORD dwReserved); }

Slika 5.3: Definicija IMarshal sučelja

Prednost korisničkog pakiranja parametara je sloboda izbora među-procesnog ili mrežnog komunikacijskog protokola, uključujući ORPC, imenovane cjevovode, TCP/IP, UDP i HTTP. Za razliku od ovoga, standardno pakiranje parametara koristi samo ORPC.

38

5.4. Protocol ORPC

Sučelje IRemoteActivation predstavlja ORPC sučelje kojeg izlaže upravitelj SCM na svakom računalu. Sučelje sadrži samo jednu metodu, RemoteActivation(), koja je oblikovana za aktivaciju COM objekta na udaljenom računalu. Ovo je vrlo značajna osobina koja nedostaje u čistom RPC-u gdje se poslužitelj mora uvijek pokrenuti prije spajanja nekog klijenta.

Kroz sučelje IRemoteActivation, upravitelj SCM na jednom računalu kontaktira upravitelja na drugom računalu sa zahtjevom za aktivacijom objekta. Ovo je izvedeno pozivom metode IRemoteActivation::RemoteActivation() od strane SCM klijenta kojoj se kao jedan od argumenata pridruži identifikator objekta CLSID. Metoda RemoteActivation() vraća pokazivač sučelja zahtijevanog objekta i dvije specijalne vrijednosti: identifikator kazaljke sučelja (IPID) i identifikator eksportera objekta (OXID). Identifikator pokazivača sučelja je vrijednost koja identificira sučelje koje pripada određenoj instanci objekta u procesu, dok identifikator eksportera objekta identificira RPC informacije povezivanja, u obliku niza znakova, potrebne za spajanje na sučelje određeno identifikatorom pokazivača sučelja.

5.4.1. Pakiranje globalnog jedinstvenog identifikatora Globalni jedinstveni identifikator (engl. Globally Unique Identifier - GUID), prenošen preko mreže, mora biti interpretiran u skladu s IDL definicijom GUID-a koja je navedena na slici 5.4.

typedef struct _GUID { DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[8]; } GUID;

Slika 5.4: Definicija GUID-a

Kako je GUID pakiran u little-endian obliku, originalni GUID je rekonstruiran u dva koraka. Prvo, GUID nađen u mrežnom paketu mora biti formatiran u izgled standardnog GUID-a. Na primjer, neka se u mrežnom paketu nalazi GUID 78 56 34 12 34 12 34 12 12 34 12 34 56 78 9A BC [45]. U prvom koraku, prikazanom na slici 5.5, GUID je grupiran u standardni format. Nakon toga, kako bi se dobio stvarni GUID u obzir se mora uzeti little-endian oblik. Prva tri elementa GUID strukture moraju biti preokrenuta na osnovi oktet-po-oktet. Posljednji element GUID strukture ne mora biti modificiran budući je već pohranjen u obliku jednostavnog slijeda okteta. Dakle, završeni drugi korak procesa daje stvarni GUID: 12345678-1234-1234-1234-123456789ABC.

Slika 5.5: GUID u standardnom obliku

39

5.4.2. Pozivi udaljenog objekta Pozivi metoda udaljenih COM objekata predstavljaju pozive prema normi DCE RPC u smislu da se standardni paket zahtjeva, poznat pod nazivom Protocol Data Unit (PDU), prenosi mrežom s ciljem izvršavanja određene metode. PDU predstavlja osnovnu jedinicu komunikacije između dva računala. Paket zahtjeva sadrži sve ulazne parametre koje metoda očekuje. Kada metoda završi s izvođenjem, PDU odgovora, koji sadrži izlazne parametre metode, šalje se natrag klijentu. Postoji 19 definiranih tipova PDU paketa, prikazanih u tablici 5.1. Treba uočiti da su neki paketi specifični ili spojno-orijentiranom (SO) ili bespojnom (BS) protokolu.

Tablica 5.1: PDU tipovi

PDU Tip Protokol Vrijednost tipa

Request SO/BS 0

Ping BS 1

Response SO/BS 2

Fault SO/BS 3

Working BS 4

Nocall BS 5

Reject BS 6

Ack BS 7

Cl_cancel BS 8

Fack BS 9

Cancel_ack BS 10

Bind SO 11

Bind_ack SO 12

Bind_nak SO 13

Alter_context SO 14

Alter_context_resp SO 15

Shutdown SO 17

Co_cancel SO 18

Orphaned SO 19

40

Spojno-orijentirani protokol, poput TCP protokola, održava virtualnu vezu između klijenta i poslužitelja tijekom prijenosa i garantira dostavu poruka u istom slijedu u kojem su i poslane. Bespojni protokol, kao što je UDP protokol, ne održava vezu između klijenta i poslužitelja, i ne garantira dostavu poruke klijenta poslužitelju. Štoviše, i u slučaju da su poruke dostavljene, mogu stići u drugačijem redoslijedu. Prema unaprijed definiranim postavkama, DCOM koristi UDP protokol između Windows računala, ali to ga ne čini nepouzdanim, budući protokol ORPC osigurava robusnost implementacijom mehanizma svrstavanja poruka i potvrda prijenosa. Paket protokola ORPC se može sastojati od tri dijela, od kojih je samo prvi obvezan:

- Zaglavlje PDU paketa koje sadrži upravljačke informacije protokola. - Tijelo PDU paketa koje sadrži podatke. Na primjer, tijelo PDU zahtjeva ili

odgovora sadrži podatke koji predstavljaju ulazne ili izlazne parametre operacije. Ove informacije pohranjene su u formatu mrežnog predstavljanja podataka (engl. Network Data Representation – NDR).

- Verifikator autentifikacije koji sadrži podatke specifične protokolu autentifikacije. Na primjer, protokol autentifikacije može osiguravati integritet paketa uključivanjem kriptirane kontrolne sume unutar verifikatora autentifikacije.

Zaglavlje PDU paketa korišteno za bespojne protokole definirano je IDL strukturom navedenom u nastavku.

typedef struct { unsigned small rpc_vers = 4; // osnovna verzija RPC // protokola unsigned small ptype; // tip paketa unsigned small flags1; // zastavice paketa unsigned small flags2; // zastavice paketa byte drep[3]; // oznaka formata prikaza // podataka unsigned small serial_hi; // gornji oktet serijskog // broja GUID object; // identifikator objekta // (sadrži IPID) GUID if_id; // identifikator sucelja (IID) GUID act_id; // identifikator aktivnosti unsigned long server_boot; // vrijeme podizanja // poslužitelja unsigned long if_vers; // verzija sucelja unsigned long seqnum; // broj sekvence unsigned short opnum; // broj operacije unsigned short ihint; // znak sucelja unsigned short ahint; // znak aktivnosti unsigned short len; // duljina tijela paketa unsigned short fragnum; // broj fragmenta unsigned small auth_proto; // id protokola // autentifikacije unsigned small serial_lo; // donji oktet serijskog broja } dc_rpc_cl_pkt_hdr_t;

Slika 5.6: PDU zaglavlje za bespojne protokole

Kao što je već spomenuto, DCOM mrežni protokol prenosi parametre metoda u formatu NDR definiranim unutar specifikacije DCE RPC. Format NDR definira kako se svi primitivni tipovi podataka, koje razumije IDL, pakiraju u podatkovne pakete za

41

mrežni prijenos. Jedino proširenje norme NDR od strane okruženja DCOM je podrška za pakiranjem kazaljke sučelja.

5.5. Sigurnost u DCOM okruženju

DCOM posjeduje više razina sigurnosti. Mnogo sigurnosnih obilježja DCOM-a posuđeno je iz ostalih podsustava. Protokol ORPC pruža osnovu za COM sigurnost, te veliki dio korištenih koncepata dolazi direktno iz ORPC-a. Osnovnu sigurnosnu razinu DCOM-a pruža sama mreža, budući osigurava određenu razinu sigurnosti prilikom prijave. Ako je, na primjer, lokalna mreža unutar Windows domene, domenski kontroler upravlja i ograničava mrežne prijave. Sigurno mrežno okruženje uveliko poboljšava cjelokupnu sigurnost okruženja DCOM. Okruženje COM implementira sigurnost korištenjem sučelja Security Support Provider Interface (SSPI). Ovo omogućuje COM-u korištenje bilo kojeg pružatelja sigurnosti koji implementira sučelje SSPI. Osnovni razlog ovome je ideja o prenosivosti okruženja COM na različite platforme. Windows NT sigurnost, čiji je precizniji naziv NT Lan Manager Security Service Provider (NTLMSSP), je prvi pružatelj sigurnosti koji implementira sučelje SSPI. Pružatelj NTLMSSP je dostupan na svim Windows NT radnim stanicama i poslužiteljima, te je tako prvi kandidat (a ponekad i jedini) za korištenje kod implementacije DCOM sigurnosti [9].

5.5.1. Sigurnost u Windows NT okruženju NT sigurnost bazirana je na sigurnosnim opisnicima. Sigurnosni opisnici opisuju sigurnosne atribute NT objekata, koji uključuju direktorije, datoteke, pristupe, dretve, procese, semafore, događaje, upravljačke programe i ostalo. Svaki sigurnosni opisnik posjeduje vlasnički SID (sigurnosni ID), SID grupe, diskrecijsku listu kontrole pristupa (engl. Discretionary Access Control List - DACL) i sustavsku listu kontrole pristupa (engl. System Access Control List - SACL). Postoje dvije vrste sigurnosnih opisnika: samo-relativni (engl. self-relative), koji su zatvorene strukture i sadrže same sigurnosne informacije, i apsolutni, koji sadrže kazaljke na sigurnosne informacije. Važno je primijetiti razliku, jer apsolutni sigurnosni opisnici ne mogu biti pohranjeni u datoteku ili preneseni mrežom upravo zbog postojanja kazaljki. Dvije ACL liste u sigurnosnom opisniku predstavljaju liste stavki kontrole pristupa (engl. Access Control Element - ACE). Treba napomenuti da postoji razlika između prazne diskrecijske liste kontrole pristupa i ne postojanja diskrecijske liste kontrole pristupa. Prazna DACL lista znači da niti jedna dozvola nije pridijeljena dok ne postojanje DACL liste znači upravo suprotno, odnosno da su sve dozvole pridijeljene. Kada se korisnik prijavi, pridjeljuje mu se token pristupa koji sadrži skup SID identifikatora za tog korisnika i sjednicu. Skup SID identifikatora se sastoji od jednog SID identifikatora koji jedinstveno identificira korisnika i po jednog SID identifikatora za svaku grupu čiji je korisnik član.

42

5.5.2. Sigurnost u COM okruženju Sigurnost u COM okruženju se veže uz četiri važne teme, a to su autentifikacija, pretvaranje, pokretanje i pristup. Autentifikacijska razina govori COM-u o razini na kojoj se želi autentificirati klijenta. U nastavku su navedene razine autentifikacije dostupne u COM-u.

- RPC_C_AUTHN_LEVEL_DEFAULT – Koristi unaprijed postavljenu autentifikacijsku razinu autentifikacijske usluge.

- RPC_C_AUTHN_LEVEL_NONE – Nema autentifikacije.

- RPC_C_AUTHN_LEVEL_CONNECT – Autentificira se samo prilikom spajanja.

- RPC_C_AUTHN_LEVEL_CALL – Autentificira se svaki poziv.

- RPC_C_AUTHN_LEVEL_PKT – Autentificira se svaki paket.

- RPC_C_AUTHN_LEVEL_PKT_INTEGRITY – Isto kao i kod razine RPC_C_AUTHN_LEVEL_PKT uz verifikaciju sačuvanog integriteta podataka prilikom prijenosa.

- RPC_C_AUTHN_LEVEL_PKT_PRIVACY – Isto kao i kod razine RPC_C_AUTHN_LEVEL_PKT_INTEGRITY uz kriptiranje paketa.

Pretvaranje je proces u kojem korisnik, proces ili dretva pokušava igrati ulogu drugog korisnika kako bi pridobio njegov sigurnosni kontekst. Postoje sljedeće razine pretvaranja u COM okruženju:

- Anonymous – Nije dozvoljeno pretvaranje. - Identify – Nije dozvoljeno pretvaranje, osim za provjeru dozvola klijenta. - Impersonate – Dozvoljeno je pretvaranje, osim prilikom poziva drugih

objekata. - Delegate – Dozvoljeno je pretvaranje, uključujući i prilikom poziva drugih

objekata. Pretvaranje je važno jer poslužitelj obavlja posao za klijenta, za što mu je potreban definiran skup sigurnosnih privilegija. Ponekad je važno da poslužitelj dobije prava klijenta kako bi obavio zadatak koji se može ispuniti samo pod korisničkim računom klijenta, dok je također ponekad potrebno ograničiti prava dostupna klijentu kako bi se ograničila potencijalna šteta malicioznih poslužitelja. Sigurnost pokretanja pridjeljuje korisniku dozvole za pokretanje (aktivaciju) objekata. Dozvole pokretanja COM objekata pohranjene su u registru pod ključem AppID, koji je uveden s okruženjem DCOM kako bi jedinstveno identificirao modul. Svaki modul (izvršna datoteka ili DLL) može sadržavati više od jednog COM objekta, a svaki COM objekt ima jedinstveni identifikator klase (CLSID). Stoga, ključ AppID je uveden kako bi se reduciralo održavanje registra, a vrijednost mu predstavlja samo-relativni sigurnosni opisnik. Sigurnost pristupa pridjeljuje korisnicima dozvole za pozive nad utvrđenim objektima. Postavljanje dozvola pristupa identična je kao i kod sigurnosti pokretanja.

43

6. Raspodijeljeno programiranje u Microsoft .NET okruženju

6.1. Uvod

.NET Remoting pruža radno okruženje koje omogućava međusobnu interakciju objekata između aplikacijskih domena*. Radno okruženje osigurava mnogo usluga, uključujući podršku za aktivaciju i životni vijek objekata, kao i komunikacijske kanale odgovorne za prijenos poruka do udaljenih aplikacija i u suprotnom smjeru. Formateri se koriste za kodiranje i dekodiranje poruka prije nego se prenesu kanalom. Aplikacije mogu koristiti binarno kodiranje, u slučajevima gdje su performanse od kritične važnosti, ili XML kodiranje, gdje je esencijalna interoperabilnost s ostalim raspodijeljenim tehnikama. XML kodiranje koristi protokol Simple Object Access Protocol (SOAP) za transport poruka iz jedne aplikacijske domene u drugu. .NET Remoting je oblikovan vodeći računa o sigurnosti, stoga je omogućeno mnogo načina na koje ponori** kanala mogu pristupiti porukama i serijaliziranom toku podataka prije nego je taj tok prenesen preko kanala. Upravljanje životnim vijekom udaljenih objekata bez podrške inherentnog radnog okruženja je često teško. .NET Remoting pruža nekoliko aktivacijskih modela na izbor. Ovi modeli spadaju u sljedeće dvije kategorije [7]:

- Klijent-aktivirani objekti (engl. Client-Activated Object - CAO) - Poslužitelj-aktivirani objekti (engl. Server-Activated Object - SAO)

Klijent-aktivirani objekti nalaze se pod kontrolom upravitelja životnog vijeka baziranog na najmu***, koji osigurava da je objekt oslobođen kada mu najam istekne. U slučaju poslužitelj-aktiviranih objekata, programeri imaju izbor odabira single call ili singleton modela. Životni vijek singleton objekata također je kontroliran najmom.

6.2. .NET Remoting arhitektura

.NET Remoting arhitektura, kao što je prikazano na slici 6.1, zasniva se na pet osnovnih vrsta objekata [15]:

- Zamjenski objekti – Ovi objekti oponašaju udaljene objekte i prosljeđuju pozive.

- Poruke – Objekti poruka sadrže potrebne podatke za izvršavanje poziva udaljene metode.

- Ponori poruka – Ovi objekti dozvoljavaju korisnički definirano procesiranje poruka tijekom udaljenog poziva.

* Logička granica oko svake .NET aplikacije koju stvara .NET izvršno okruženje (Common Language Runtime - CLR) [14]. ** Objekti koji imaju pristup prenošenoj poruci poziva ili odgovora udaljene metode kako bi obavljali određene obrade nad porukom. Lanac ovakvih objekata na strani klijenta i poslužitelja su sastavni dio kanala. *** Objekt koji upravlja životnim vijekom nekog drugog objekta.

44

- Formateri – Ovi objekti su također ponori poruka i serijaliziraju poruku u prijenosni format poput protokola SOAP. Također imaju i funkciju deserijalizacije, odnosno stvaranja konkretnih objekata iz prijenosnog formata.

- Prijenosni kanali – Također su ponori poruka koji prenose serijaliziranu poruku udaljenom procesu, na primjer putem protokola HTTP.

Slika 6.1: .NET Remoting arhitektura

Umjesto rada sa stvarnim referencama objekata (spremničke reference, kazaljke), prilikom korištenja udaljenih objekata klijent aplikacija može izvršavati metode samo nad zamjenskim objektima. Ovi objekti oponašaju ciljane objekte, te kao posljedica toga pružaju isto sučelje. Umjesto izvršavanja bilo koje metode samostalno, zamjenski objekti prosljeđuju svaki poziv metode .NET Remoting radnom okruženju u obliku objekta Message. Ova poruka prolazi kroz ponore poruka, sve dok na kraju nije obrađena poslužiteljem, gdje poruka prolazi kroz drugi skup ponora poruka te je na posljetku poziv izvršen nad stvarnim ciljnim objektom. Poslužitelj tada stvara povratnu poruku koja se šalje natrag zamjenskom objektu. Zamjenski objekt obrađuje povratnu poruku i pretvara je u parametre i povratnu vrijednost metode, što se šalje natrag klijent aplikaciji.

6.2.1. Stvaranje zamjenskog objekta Prilikom korištenja operatora new ili poziva statičke metode Activator.GetObject() kako bi se došlo do reference udaljenog objekta, .NET Remoting radno okruženje generira dva zamjenska objekta. Prvi je instanca generičkog zamjenskog objekta TransparentProxy, koji će ujedno biti i povratna vrijednost operatora new. Svaki poziv metode nad referencom udaljenog objekta je u stvari poziv nad objektom TransparentProxy. Ovaj zamjenski objekt sadrži referencu na drugi generirani zamjenski objekt klase RemotingProxy, koja nasljeđuje apstraktnu klasu RealProxy. Tijekom faze stvaranja zamjenskog objekta, reference na lance ponora poruka na strani klijenta dobavljaju se korištenjem pružatelja ponora koji su dohvaćeni prilikom stvaranja komunikacijskog kanala. Ove reference pohranjene su u objektu Identity sadržanom unutar objekta RealProxy.

45

6.2.2. Stvaranje poruke Tijekom poziva metode udaljenog objekta, TransparentProxy stvara objekt MessageData i prosljeđuje ga metodi PrivateInvoke() objekta RealProxy. Objekt RealProxy tada generira novi objekt Message i poziva metodu InitFields(), kojoj kao parametar prosljeđuje objekt MessageData. Objekt Message sada može popuniti svoja svojstva koristeći reference unutar objekta MessageData.

Za sinkrone pozive, objekt RealProxy obavlja sve pozive potrebnih metoda, uključujući metode Invoke(), InternalInvoke() i CallProcessMessage(). Posljednja metoda će dohvatiti lanac ponora poruka objekta Identity i pozvati metodu SyncProcessMessage() nad prvim ponorom poruke koji implementira sučelje IMessageSink.

Kada je završeno procesiranje poziva, vraća se objekt IMessage koji sadrži poruku odgovora. Objekt RealProxy će pozvati svoju metodu HandleReturnMessage() koja provjerava out/ref parametre i poziva metodu PropagateOutParameters()nad objektom Message.

.NET Remoting poruka predstavlja objekt rječnik* sakriven iza sučelja IMessage. Iako je svaka poruka bazirana na ovom sučelju, .NET radno okruženje definira nekoliko specijalnih tipova, poput poruka ConstructionCall i MethodCall (zajedno s odgovarajućim povratnim porukama). Glavna razlika između ovih tipova poruka je definicija nekoliko stavki u internom rječniku. Dok prolazi kroz lanac ponora, poruka prođe kroz najmanje dvije važne točke: formater i prijenosni kanal. Formater je specijalni tip ponora koji kodira interni rječnik u neki oblik protokola na "žici" poput protokola SOAP ili binarnog prikaza. Prijenosni kanal prenosi serijaliziranu poruku iz jednog procesa u drugi. Na odredišnoj strani, rječnik poruke se obnavlja iz protokola na "žici" kroz poslužiteljski formater. Nakon toga, poruka prolazi kroz nekoliko poslužiteljskih MessageSink objekata dok ne stigne do razašiljača. Razašiljač prevodi poruku u stvarni poziv metode zasnovan na stogu koji će se izvršiti nad ciljnim objektom. Nakon izvršavanja metode, povratna poruka je generirana za većinu poziva (izuzevši one-way** pozive) i poslana natrag kroz različite ponore dok ne dosegne zamjenski objekt na strani klijenta, gdje se konvertira u dotičnu povratnu vrijednost ili iznimku. Postoji nekoliko vrsta poruka. Svaka poruka je predstavljena posebnom klasom ovisno o vrsti poziva na koji se odnosi. Ovaj objekt implementira sučelje IDictionary kako bi pružio pristup svojim svojstvima zasnovan na kombinaciji ključ/vrijednost. Djelomična definicija klase MethodCall prikazana je na slici 6.2.

public class System.Runtime.Remoting.Messaging.MethodCall : { // samo su svojstva prikazana public int ArgCount { virtual get; } public object[] Args { virtual get; } public bool HasVarArgs { virtual get; } public int InArgCount { virtual get; } public object[] InArgs { virtual get; } public LogicalCallContext LogicalCallContext { virtual get; }

* Objekt koji implementira sučelje IDictionary. ** Poziv koji ne vraća nikakvu vrijednost.

46

public MethodBase MethodBase { virtual get; } public string MethodName { virtual get; } public object MethodSignature { virtual get; } public IDictionary Properties { virtual get; } public string TypeName { virtual get; } public string Uri { virtual get; set; } }

Slika 6.2: Definicija klase MethodCall

Druga vrsta poruke, korištena prilikom stvaranje CAO objekata, je predstavljena klasom ConstructionCall koja nasljeđuje klasu MethodCall i pruža sljedećih nekoliko svojstava:

public class System.Runtime.Remoting.Messaging.ConstructionCall : { // samo su svojstva prikazana public Type ActivationType { virtual get; } public string ActivationTypeName { virtual get; } public IActivator Activator { virtual get; virtual set; } public object[] CallSiteActivationAttributes { virtual get; } public IList ContextProperties { virtual get; } }

Slika 6.3: Definicija klase ConstructionCall

6.2.3. Ponori poruka Prijenos poruke od aplikacije klijenta do poslužiteljskog objekta obavlja se kroz tzv. ponore poruka. Ponor jednostavno primi poruku od drugog objekta u lancu ponora, obradi poruku te je pošalje sljedećem ponoru u lancu.

Postoje tri osnovna sučelja za ponore poruka: IMessageSink, IClientChannelSink i IServerChannelSink. Kao što se vidi na slici 6.4, sučelje IMessageSink definira dvije metode za procesiranje poruke i svojstvo za dohvat reference sljedećeg ponora u lancu.

public interface IMessageSink { IMessageSink NextSink { get; } IMessageCtrl AsyncProcessMessage(IMessage msg, ImessageSink replySink); IMessage SyncProcessMessage(IMessage msg); }

Slika 6.4: Definicija sučelja IMessageSink

Kad sučelje IMessageSink primi poruku korištenjem ili metode SyncProcessMessage() ili AsyncProcessMessage(), prvo provjerava da li može obraditi ovu poruku. Ako može, procesirat će je, te proslijediti objektu IMessageSink referenciranom svojim svojstvom

NextSink. U nekoj točki lanca, poruka doseže formater koji serijalizira poruku u definirani format i prosljeđuje je sekundarnom lancu IClientChannelSink objekata. Formateri po konvenciji implementiraju sučelje IClientFormatterSink, koje predstavlja kombinaciju sučelja IMessageSink i IClientChannelSink. Deklaracija sučelja IClientChannelSink je prikazana na slici 6.5.

47

public interface IClientChannelSink { // Svojstva IClientChannelSink NextChannelSink { get; } // Metode void AsyncProcessRequest(IClientChannelSinkStack sinkStack, IMessage msg, ITransportHeaders headers, Stream stream); void AsyncProcessResponse(IclientResponseChannelSinkStack sinkStack, object state, ITransportHeaders headers, Stream stream); Stream GetRequestStream(IMessage msg, ITransportHeaders headers); void ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ref ITransportHeaders responseHeaders, ref Stream responseStream); }

Slika 6.5: Definicija sučelja IClientChannelSink

Glavna razlika između objekata koji implementiraju sučelje IMessageSink i sučelje IClientChannelSink je u tome što prvi može pristupati i mijenjati izvorni rječnik, neovisno o formatu serijalizacije, dok drugi ima pristup već serijaliziranoj poruci u obliku toka podataka. Slike 6.6 i 6.7 prikazuju razne faze prolaska poruke kroz lanac ponora na strani klijenta odnosno poslužitelja [15].

TransparentProxy

RealProxy

ClientContextTerminatorSink[IMessageSink]

Opcionalni dinamički ponori[IDynamicMessageSink]

Opcionalno predprocesiranje[IMessageSink]

Formater[IClientFormatterSink/

IMessageSink]

Opcionalno predprocesiranje[IClientChannelSink]

Prijenosni kanal[IClientChannelSink]

Stvaranjeporuke

Obavješćivanje dinamičkih ponora

Prijenos

Opcionalno predprocesiranje

serijalizirane poruke

Formatiranje


poruke

Registrirani metodom Context.RegisterDynamicPreperty()

Podesivo tijekom stvaranje kanala

Slika 6.6: Faze prijenosa poruke na strani klijenta

48

HttpServerSocketHandler

HttpServerTransportSink[IServerChannelSink]

SDLChannelSink[IServerChannelSink]

Opcionalno predprocesiranje[IServerChannelSink]

Formater[IServerChannelSink]

Opcionalno predprocesiranje[IServerChannelSink]

DispatchChannelSink[IServerChannelSink]

CrossContextChannel[IMessageSink]

Prihvat serijalizirane poruke

?WSDL zahtjevi

Obavješćivanje konteksnih ponora

Razašiljanje poruke


poruke

Deserijalizacija


serijalizirane poruke Podesivo tijekom stvaranje kanala

Opcionalni dinamički ponori[IDynamicMessageSink]

ServerContextTerminatorSink[IMessageSink]

LeaseSink[IMessageSink]

ServerObjectTerminatorSink[IMessageSink]

StackbuilderSink[IMessageSink]

Registrirani metodom Context.RegisterDynamicPreperty()

Posljednji ponor koji obrađuje poruku

Produljenje životnog vijeka tijekom svakog poziva

Prosljeđivanje poziva ponoru

StackbuilderSink

Izvršavanje poziva nad ciljnim objektom

Poznato iz svojstva ServerIdentity

poruke

Slika 6.7: Faze prijenosa poruke na strani poslužitelja

6.2.4. Klijent/poslužitelj-aktivirani objekti Kad klijent zatraži referencu na poslužitelj-aktivirani objekt, poruka se neće odmah prenijeti poslužitelju već samo u trenutku poziva metode nad ovom referencom. Ovisno o konfiguraciji ovih objekata, poslužitelj tada odlučuje da li će stvoriti novu instancu objekta ili će se ponovno upotrijebiti postojeći objekt. SAO objekti mogu biti označeni kao singleton ili singlecall objekti. U prvom slučaju, jedna instanca poslužuje zahtjeve svih klijenata u višedretvenom modelu, dok će se u drugom stvoriti novi objekt za svaki zahtjev te nakon obrade uništiti. Objekti tipa singlecall ne mogu zadržavati informacije o stanju (engl. stateless), budući će sve interne varijable biti uklonjene na kraju poziva metode. Razlog korištenja objekata ovog tipa je mogućnost primjene na vrlo skalabilan način. Ovi objekti mogu biti locirani na različitim računalima s posrednim elementom za multipleksiranje odnosno balansiranje opterećenja, što ne bi bilo moguće (ili bi bilo

49

puno kompliciranije) prilikom korištenja stateful objekata, odnosno objekata koji zadržavaju stanje između poziva metoda. S druge strane, samo jedna instanca objekta singleton može postojati u bilo kojem trenutku. Prilikom zaprimanja zahtjeva klijenta, poslužitelj provjerava svoje interne tablice kako bi ustanovio da li već postoji instanca tražene klase. Ako ne postoji, ovaj objekt će se stvoriti i pohraniti u tablicu. Nakon ove provjere metoda će se izvršiti. Poslužitelj garantira postojanje točno jedne ili nijedne dostupne instance u bilo kojem trenutku.

Metoda RemotingServices.Marshal() pruža mogućnost publiciranja objekta koji poprima svojstva objekta singleton, a bio je stvoren na strani poslužitelja. Klijent-aktivirani objekti ponašaju se uglavnom kao normalni .NET objekti (ili COM objekti). Kad se naiđe na zahtjev za stvaranje objekta na strani klijenta (korištenjem metode Activator.CreateInstance() ili operatora new), aktivacijska poruka se šalje poslužitelju gdje se udaljeni objekt stvara. Na strani klijenta se stvara zamjenski objekt, na isti način kao i kod SAO objekta, koji sadrži referencu, tipa ObjRef, na poslužiteljski objekt.

6.3. Upravljanje životnim vijekom objekta

Tehnike CORBA i DCOM koriste brojanje raspodijeljenih referenci. Kod tehnike DCOM, na primjer, objekti poslužitelja sadrže brojila koja se oslanjaju na metode AddRef() i Release() na isti način koji se koristi i za obične COM objekte. Na žalost, ovo ima nekoliko velikih nedostataka; svaki poziv za povećanje ili smanjenje brojila referenci mora putovati udaljenom objektu bez stvarne koristi za aplikaciju. Kod DCOM-a, klijenti također prozivaju (engl. ping) poslužitelja u određenim intervalima kako bi signalizirali da su još uvijek aktivni. I prozivanje i pozivi za promjenu brojila referenci rezultiraju povećanim mrežnim opterećenjem, a prozivanje također neće niti funkcionirati s pojedinim sigurnosnim stijenama koje propuštaju samo stateless HTTP veze. Zbog ovih implikacija, Java RMI je uveo uslugu životnog vijeka objekata zasnovanu na najmu koja je vrlo slična usluzi korištenoj u .NET Remoting okruženju. Koncept zasnovan na najmu u osnovi dodjeljuje time-to-live (TTL) broj svakom objektu stvorenom na poslužitelju. Upravitelj najma tada proziva sve objekte na strani poslužitelja u određenim intervalima i smanjuje ovaj TTL. U trenutku kada TTL dosegne nulu, objekt se označava da je vremenski istekao i spreman za proces sakupljanja smeća. Također, za svaki poziv metode nad udaljenim objektom, TTL se povećava kako bi se osiguralo da najam trenutno korištenih objekata ne istekne prije vremena. U stvarnosti, postoje aplikacije u kojima objekti mogu postojati a da se ne koriste čitavo vrijeme. Čisti TTL-pristup bi rezultirao prebrzim istekom najma ovih objekata. Zbog ovoga, .NET Remoting radno okruženje također podržava koncept nazvan sponzorstvo. Za svaki objekt registrira se jedan ili više sponzora. U trenutku kada TTL dosegne nulu, upravitelj najma kontaktira svakog sponzora i pita da li želi povećati životni vijek objekta. Kada niti jedan od njih ne odgovori pozitivno u određenom vremenu objekt se označava za sakupljanje smeća.

50

Sponzor je također objekt klase MarshalByRefObject, što znači da može biti smješten na klijentu, poslužitelju ili bilo kojem drugom računalu koji je dostupan preko .NET Remoting tehnike. Prilikom stvaranja najma, postavljaju se sljedeće informacije, prikazane u tablici 6.1:

Tablica 6.1: Svojstva najma

Svojstvo Pretpostavljena Vrijednost Opis

InitialLeaseTime 5 minuta Inicijalni TTL nakon stvaranja objekta.

RenewOnCallTime 2 minute

Minimalno vrijeme na koje se TTL postavlja nakon poziva metode nad objektom. Ova vremena nisu aditivna. Na primjer, pozivanje metode tisuću puta neće rezultirati TTL-om od 2000 minuta, već jednim od 2 minute.

SponsorShipTimeout 2 minute

Kada se sponzori registriraju za najam, upravitelj najma će ih kontaktirati prilikom isteka TTL-a. Tada, sponzori mogu zatražiti dodatno vrijeme najma za pojedini objekt. Ako niti jedan sponzor ne reagira tijekom vremena definiranog ovim svojstvom, najam će isteći i objekt će biti dostupan algoritmu sakupljanja smeća.

Svaki put kada je objekt MarshalByRefObject instanciran (bilo kao CAO ili SAO objekt), radno okruženje poziva metodu InitializeLifetimeService() objekta koja vraća objekt ILease. U unaprijed ostvarenoj implementaciji (odnosno, kada se ova metoda ne preoptereti) radno okruženje poziva metodu LifetimeServices.GetLeaseInitial(), koja vraća objekt ILease s unaprijed definiranim vrijednostima prikazanim u tablici 6.1. Upravitelj najma se izvršava u pozadini svake aplikacije na strani poslužitelja i provjerava TTL brojeve svih udaljenih objekata. Također, koristi mjerač vremena koji poziva metodu upravitelja LeaseTimeAnalyzer() u određenim intervalima. Inicijalna vrijednost ovog intervala je 10 sekundi, ali se može promijeniti korištenjem sljedeće linije izvornog teksta programa:

LifetimeServices.LeaseManagerPollTime = TimeSpan.FromSeconds(1);

ili prilikom korištenja konfiguracijskih datoteka, dodavanjem postavki prikazanih na slici 6.8:

<configuration> <system.runtime.remoting> <application> <lifetime leaseManagerPollTime="1s" /> </application> </system.runtime.remoting> </configuration>

Slika 6.8: Definiranje intervala provjere TTL-ova pomoću konfiguracijske datoteke

Sponzori moraju implementirati sučelje ISponsor, koje je definirano u System.Runtime.Remoting.Lifetime prostoru nazivlja. Sadrži samo jednu metodu, koju će pozvati upravitelj najma nakon isteka TTL-a najma, prikazanu na slici 6.9.

51

public interface ISponsor { TimeSpan Renewal(System.Runtime.Remoting.Lifetime.ILease lease) }

Slika 6.9: Sučelje ISponsor

Sponzor mora vratiti vremenski interval koji specificira novi TTL za objekt. Ako sponzor odluči ne produljiti vrijeme najma, onda može vratiti vrijednost TimeSpan.Zero.

6.4. .NET Remoting sigurnost

Općeniti problem .NET Remoting tehnike je u tome što radno okruženje ne uključuje standardni način autentifikacije. Umjesto toga, Microsoft je dao sučelja kako bi se mogla koristiti bilo koja autentifikacijska i kriptografska varijanta implementiranjem korisnički definiranih ponora i pružatelja ponora. Trud oko implementacije ovih ponora je opravdan prilikom razvoja velikih raspodijeljenih aplikacija koje se moraju integrirati s već instaliranim rješenjima vanjskih proizvođača (engl. third-party). Za većinu ostalih aplikacija može se koristiti sustav Internet Information Services (IIS) za autentificiranje zahtjeva s obzirom na korisničke račune operacijskog sustava Windows. Ova funkcionalnost nije dimenzionirana posebno za .NET Remoting, ali važi za sve IIS aplikacije, uključujući statičke HTML stranice i ASP.NET Web aplikacije.

6.4.1. Autentifikacija Prilikom korištenja autentifikacije unutar sustava IIS, potrebna je promjena u izvornom tekstu programa klijenta za slanje korisničkih imena i šifri poslužitelju. Za ovu funkciju potrebno je postaviti svojstva ponora kanala. To se postiže pozivom statičke metode ChannelServices.GetChannelSinkProperties(), koja prima kao parametar referencu na udaljeni objekt (odnosno referencu na zamjenski objekt). Ova funkcija vraća objekt IDictionary koji dozvoljava postavljanje dodatnih svojstava uključujući korisničko ime i šifru, kao što se vidi na slici 6.10.

IDictionary props = ChannelServices.GetChannelSinkProperties(mgr); props["username"] = "dummyremotinguser"; props["password"] = "12345";

Slika 6.10: Postavljanje korisničkog imena i šifre

6.4.2. Autorizacija Korištenjem sučelja IPrincipal iz System.Security.Principal prostora nazivlja, moguće je verificirati grupno članstvo pojedinog korisnika. Kako bi se pristupilo trenutnom principalu dretve, koristi se svojstvo System.Threading.Thread.CurrentPrincipal koje sustav IIS postavi prilikom korištenja autentificiranih poziva. Metoda IsInRole() objekta IPrincipal dozvoljava provjeru članstva trenutnog korisnika u specifičnoj Windows grupi. Primjer autorizacije korisnika prikazan je na slici 6.11.

52

String machinename = Environment.MachineName; IPrincipal principal = System.Threading.Thread.CurrentPrincipal; if (! principal.IsInRole(machinename + "\\RemotingUsers")) { throw new UnauthorizedAccessException( "Korisnik nije clan grupe RemotingUsers"); }

Slika 6.11: Primjer autorizacije korisnika

6.4.3. Sigurni prijenos podataka Smještaj komponenti unutar okruženja IIS ima svoju prednost kod kriptiranja prijenosnog kanala, budući je moguće jednostavno iskoristiti ugrađene SSL (engl. Secure Socket Layer) funkcionalnosti. O tehnologiji SSL će više biti riječi u poglavlju 8. Sve što je potrebno je instaliranje certifikata na strani poslužitelja i promjena adrese URL u konfiguracijskoj datoteci na strani klijenta. Nakon promjene jedne linije ("http:" u "https:"), sav promet će biti siguran, uključujući HTTP zaglavlja, autentifikacijske informacije i, naravno, podatke. Za SSL enkripciju se ponekad smatra da stvara veliki dodatni vremenski trošak (engl. overhead). Ovo nije uvijek istinito, budući se asimetrična kriptografija izvršava samo tijekom procesa uspostave sigurne HTTP veze. Ova sigurna veza će se ponovno iskoristiti i na taj način smanjiti dodatni vremenski trošak.

53

7. Ostale tehnike

7.1. Web usluga

Web usluge (engl. Web services) predstavljaju tehniku koja omogućava integraciju komponenti u raspodijeljenim sustavima. Ono što ovu tehniku izdvaja od ostalih opisanih tehnika jest oslanjanje na standardizirane protokole i tehnologije, kao što su općeprihvaćeni HTTP i XML, kako bi se omogućila komunikacija između udaljenih komponenti. Web usluge su implementacija uslugama orijentirane arhitekture (engl. Service Oriented Architecture) koju obilježavaju tri različite vrste komponenti: poslužitelj, posrednik i korisnik usluge. Poslužitelj omogućava pristup i korištenje usluga čija konkretna implementacija nije izravno vidljiva. Korisnik usluge preko posrednika saznaje koje su usluge dostupne i kako im može pristupiti. Kako je sama razmjena podataka implementirana korištenjem otvorenih normi, Web usluge su univerzalne i dostupne za korištenje u različitim uređajima i računalima u heterogenim okruženjima. Osnovne tehnologije korištene u Web uslugama su: XML, SOAP, WSDL i UDDI. SOAP (engl. Simple Object Access Protokol) je protokol koji se koristi za pristupanje i korištenje Web usluga. SOAP je norma koju održava World Wide Web Consortium (W3C). Bazira se na tehnologiji XML pa sve prednosti prijenosa podataka korištenjem XML-a vrijede i za SOAP. Najvažnije su platformska i jezična neovisnost, proširivost i normizacija. SOAP kao prijenosni protokol najčešće koristi, u Internet zajednici rašireni, HTTP protokol, a može koristiti i druge protokole kao što su SMTP, MSMQ, TCP, itd. Korištenje HTTP protokola kao prijenosnog protokola omogućava olakšano korištenje Web usluga u mrežama u kojima se kao zaštitni mehanizmi koriste sigurnosne stijene. SOAP protokol prolazi kroz sigurnosne stijene kroz uobičajeni pristup 80 kroz koji prolazi i ostali HTTP promet, pa ne zahtjeva otvaranje novih pristupa i narušavanje sigurnosti zaštićenog sustava. SOAP poruke enkapsulirane su unutar HTTP GET i POST metoda. Sami podaci nalaze se unutar XML dokumenta koji korisnik usluge šalje kao zahtjev za željenom uslugom. Poslužitelj obrađuje zahtjev i šalje natrag rezultat obrade također kao XML dokument. SOAP poruka sastoji se od četiri osnovna elementa: Envelope, Header, Body i Fault. Na slici 7.1 prikazana je osnovna struktura SOAP poruke.

<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header>  </soap:Header> <soap:Body>  </soap:Body> </soap:Envelope>

Slika 7.1. Struktura SOAP poruke

Element Envelope je korijenski element s definiranim prostorom nazivlja koji označava da se radi o XML dokumentu čiji je sadržaj SOAP poruka. Element Header

54

je opcionalan i ako je definiran mora biti prvi element unutar korijenskog elementa. Obično sadrži podatke o autentifikaciji ili druge podatke o samoj SOAP poruci. Unutar elementa Body u stvarnoj SOAP poruci nalaze se podaci, kao što su aplikacijski specifični podaci za poziv udaljenih metoda i njihove povratne vrijednosti. Ukoliko dođe do pogreške u komunikaciji prema SOAP protokolu unutar elementa Body pojavljuje se element Fault koji opisuje nastalu pogrešku. Osim SOAP protokola, koji se koristi za komunikaciju između klijenta i poslužitelja, postoje još dvije tehnologije koje sačinjavaju Web usluge. To su WSDL (engl. Web Services Definition Language) i UDDI (engl. Universal Description Discovery and Integration). WSDL je jezik zasnovan na XML jeziku koji opisuje funkcionalnost Web usluga. WSDL je jezik za definiranje sučelja neovisan o nekom programskom jeziku. Opisuje koje metode podržava određena Web usluga, kao i način pozivanja tih metoda. Na temelju WSDL definicije Web usluga korisnik Web usluga generira jezično ovisnu zamjensku komponentu koju koristi u svojoj aplikaciji za pristup Web uslugama. Kod poziva udaljene metode klijent poziva metodu nad zamjenskom komponentom koja taj poziv transparentno pretvara u SOAP poruku koju prosljeđuje poslužitelju. Poslanu SOAP poruku na strani poslužitelja prima posrednička komponenta, koja SOAP poruku pretvara u jezično specifični poziv metode na udaljenom računalu. Rezultate poziva pretvara u SOAP poruku koju vraća klijentu. Posrednička komponenta također se brine i o obradi eventualnih pogrešaka. U tom slučaju klijentu se vraća SOAP poruka s opisom nastale pogreške. Tehnologija UDDI pruža uslugu objavljivanja i pronalaženja određenih Web usluga. UDDI i WSDL usko su povezani. UDDI sadrži WSDL opise Web usluga. Pružatelji usluga pohranjuju opise svojih usluga u UDDI direktorij. Korisnici pretraživanjem UDDI direktorija pronalaze i preuzimaju WSDL dokument koji opisuje način pristupa i korištenje željene usluge.

7.2. XML-RPC

XML-RPC je protokol namijenjen pozivanju udaljenih procedura koji nalikuje protokolu SOAP korištenom u Web uslugama, ali je bitno jednostavniji. Protokol XML-RPC pozive udaljenih procedura na strani klijenta pretvara u XML dokumente koje poslužitelju prosljeđuje korištenjem standardnog HTTP protokola. XML-RPC poruka šalje se u obliku HTTP POST zahtjeva. Poslužitelj dekodira ovakav XML dokument pretvarajući ga u poziv i standardne strukture korištenog programskog jezika, te izvršava proceduru na koju se poziv odnosi. Rezultati poziva procedure ponovno se kodiraju u XML dokument koji se kao odgovor vraća klijentu. Upravo iz korištenja XML jezika za kodiranje poziva i vraćanje povratnih vrijednosti udaljenih procedura proizlazi osnovno svojstvo XML-RPC protokola, odnosno platformska i jezična neovisnost. Cijeli poziv XML-RPC procedure u XML dokumentu nalazi se unutar elementa <methodCall>. Naziv pozvane procedure nalazi se unutar podelementa <methodName>, a ulazni parmateri unutar podelementa <params>. Protokol XML-RPC ima ograničeni skup tipova podataka koji se mogu prenositi. Ulazni parametri kao i povratne vrijednosti udaljenih procedura mapiraju se u ovaj ograničeni skup tipova. Lista tipova podataka protokola XML-RPC prikazana je u tablici 7.1.

55

Tablica 7.1: XML-RPC tipovi podataka

XML-RPC oznaka Opis

<string> slijed znakova

<int> 32-bitni cjelobrojni tip s predznakom

<boolean> true (1) ili false (0)

<double> broj s pomičnim zarezom dvostruke preciznosti s predznakom

<dateTime.iso8601> datum i vrijeme

<base64> base64 kodirani binarni tip

<array> spremnik skupa osnovnih tipova

<struct> spremnik tipa ključ-vrijednost

Odgovor na poziv udaljene procedure sadržan je u XML dokumentu čiji je korijenski element <methodResponse>. Unutar korijenskog elementa nalazi se jedan parametar kao povratna vrijednost pozvane procedure. Osim povratne vrijednosti procedure, korijenski element može sadržavati i podatke o pogrešci koja se dogodila prilikom pozivanja procedure.

7.3. Tehnika paralelnog programiranja razmjenom poruka

Tehnika MPI (engl. Message Passing Interface) predstavlja specifikaciju za prosljeđivanje poruka, te je oblikovana s ciljem da bude norma za raspodijeljeni spremnik, prosljeđivanje poruka i paralelno računarstvo. Neki od razloga za korištenje tehnike MPI su [46]:

- Normizacija – MPI je jedina biblioteka za prosljeđivanje poruka koja se može smatrati normom. Podržana je na gotovo svim HPC (engl. High Performance Computing) platformama.

- Prenosivost – Nema potrebe za modifikacijom izvornog teksta programa prilikom prebacivanja na drugu platformu koja podržava MPI.

- Performanse – Implementacije isporučitelja programske opreme trebale bi moći iskorištavati izvorne osobine strojne opreme kako bi se optimizirala učinkovitost.

- Funkcionalnost – Postoji više od 115 rutina u normi. - Dostupnost – Dostupno je mnoštvo implementacija, kako od proizvođača

tako i unutar javnog djelokruga.

56

Ciljna platforma MPI implementacije je sustav raspodijeljenog spremnika uključujući paralelna računala, SMP (engl. Symmetric MultiProcessing) klastere, klastere radnih stanica i heterogene mreže. Sav paralelizam je isključivo eksplicitan, što znači da je programer odgovoran za identificiranje paralelizma i implementaciju rezultirajućeg algoritma korištenjem MPI rutina. Broj zadataka dediciranih izvršavanju određenog paralelnog programa je statičan. Novi zadaci se ne mogu dinamički dodavati tijekom izvršavanja programa (ovaj nedostatak je riješen u normi MPI-2). Trenutno je tehniku MPI moguće koristiti u programskim jezicima C/C++ i Fortran. Tehnika MPI koristi komunikatore i grupe, koji predstavljaju objekte čija je funkcija definiranje kolekcije procesa koji mogu međusobno komunicirati. Većina MPI rutina zahtjeva specificiranje komunikatora kao argument poziva. Slika 7.1 prikazuje predefinirani komunikator MPI_COMM_WORLD, koji uključuje sve MPI procese.

Slika 7.1: MPI_COMM_WORLD komunikator

Unutar komunikatora, svaki proces ima svoj jedinstveni cjelobrojni identifikator dodijeljen od sustava prilikom inicijalizacije procesa. Ovaj identifikator se naziva rang, te ima svojstvo da je slijedni i počinje od nule. Rang se koristi prilikom programiranja za definiranje izvorišta i odredišta poruka. Također, često ga koristi aplikacija za upravljanje izvršavanjem programa. Zbog postizanja prenosivosti, MPI definira tipove podataka prikazane u tablici 7.2. Programer može također stvarati svoje tipove podataka (izvedeni tipovi).

Tablica 7.2: MPI tipovi podataka korišteni u programskom jeziku C

MPI oznaka tipa Odgovarajuća C oznaka

MPI_CHAR signed char

MPI_SHORT signed short int

MPI_INT signed int

MPI_LONG signed long int

MPI_UNSIGNED_CHAR unsigned char

57

MPI_UNSIGNED_SHORT unsigned short int

MPI_UNSIGNED unsigned int

MPI_UNSIGNED_LONG unsigned long int

MPI_FLOAT float

MPI_DOUBLE double

MPI_LONG_DOUBLE long double

MPI_BYTE 8 binarnih znamenki; mogu se koristiti za isklju ivanje konverzije formata podataka

MPI_PACKED zapakirani/raspakirani podaci pomo u rutina MPI_Pack()/ MPI_Unpack

58

8. Usporedbe tehnika raspodijeljenog programiranja

8.1. Opis problema

Pojedine tehnike raspodijeljenog programiranja, opisane u ovom radu, međusobno su uspoređene na jednostavnom primjeru. Radi se o pojednostavljenom modelu IRC (engl. Internet Relay Chat) klijent/poslužitelj programskog sustava. Kako bi ostvario IRC funkcionalnost, poslužitelj implementira metodu posalji_poruku() koju klijent koristi za slanje svoje tekstualne poruke. U trenutku kada poslužitelj primi poruku od klijenta, poslužitelj koristi mehanizam povratnog poziva metode te obavješćuje sve registrirane klijente s primljenom porukom pozivom udaljene metode poruka_callback() implementirane od strane klijenta. Za tu svrhu, a primjenljivo na tehnike ONC RPC, CORBA i Java RMI, poslužitelj također implementira metode registriraj_callback() i odjavi_callback(). Tehnika DCOM ima indirektnu podršku za događaje preko biblioteke ATL (engl. Active Template Library) [34], dok .NET Remoting ima direktnu podršku za događaje te na taj način rješava problem dvosmjerne komunikacije. Osim ispitivanja prijenosa teksta, poželjno je saznati i ponašanje tehnika prilikom prijenosa numeričkih tipova podataka. U tu svrhu, poslužitelj također implementira i sljedeće metode:

- int posalji_int1(int i1)

- int posalji_int2(int i1, int i2)

- int posalji_int3(int i1, int i2, int i3)

- int posalji_int4(int i1, int i2, int i3, int i4)

- int posalji_int5(int i1, int i2, int i3, int i4, int i5)

- int posalji_byte_array(byte array[])

- int posalji_int_array(int array[])

- int posalji_double_array(double array[])

Implementacija IRC funkcionalnosti prikazana je u tablici 8.4, dok je implementacija prijenosa numeričkih podataka trivijalna te je njen izvorni tekst izostavljen u ovom radu. Za dodatne radove vezane uz usporedbu pojedinih tehnika raspodijeljenog programiranja vidjeti [23], [25], [26], [31] i [35].

8.2. Korištena programska i strojna potpora

- ONC RPC – Korištena je open-source* implementacija protokola ONC/RPC for Windows NT i razvojno okruženje Microsoft Visual C++ 6.0.

* Ostvarenje čiji je izvorni tekst programa dostupan javnosti.

59

- CORBA – Korištene su dvije implementacija posrednika ORB u Javi, J2SE i JacORB, te razvojno okruženje Sun ONE Studio 5 Standard Edition. JacORB predstavlja open-source implementaciju norme CORBA [37].

- Java RMI – Korišteno je razvojno okruženje Sun ONE Studio 5 Standard Edition.

- DCOM – Korišteno je razvojno okruženje Microsoft Visual C++ 6.0. - .NET Remoting – Korišteno je razvojno okruženje Microsoft Visual

Studio .NET 2003. Korišteno je binarno kodiranje i komunikacijski kanal TcpChannel.

- XML-RPC – Korištena je implementacija protokola XML-RPC u Javi (Apache XML-RPC) i razvojno okruženje Sun ONE Studio 5 Standard Edition.

Kao platforma korišten je Microsoft Windows XP Professional operacijski sustav. Za strojnu potporu, korištena su dva računala sljedećih karakteristika: Pentium 4, 3.2 GHz, 1 GB RAM. Kao mrežna potpora, korištena je FastEthernet (100 Mbps) mreža.

8.3. Pojedina svojstva usporedbe

U nastavku je prikazan pregled nekoliko glavnih čimbenika koji će poslužiti za usporedbu obrađenih tehnika raspodijeljenog programiranja. To su efikasnost, koja je mjerena u vremenu i podatkovnoj količini poziva udaljene procedure, mogućnosti pojedine tehnike, stabilnost, prenosivost, lakoća programiranja te na kraju sigurnost.

8.3.1. Efikasnost Kako bi rezultati usporedbe efikasnosti bili vjerodostojni, korišten je analizator mrežnog prometa kojim se mjerila ukupna količina podataka prenesena preko mreže prilikom poziva metode posalji_poruku() koja ne vraća nikakvu vrijednost. Kao argument metode pridružen je tekstualni niz od 12 znakova. Sve testirane tehnike koriste jedan oktet za prikaz jednog znaka tekstualnog niza osim tehnike DCOM, koja koristi normu Unicode za prikaz tekstualnog niza, te joj je stoga potrebno 24 okteta za pohranu 12 znakova teksta. U obzir je uzeta komunikacija u oba smjera. Rezultati su prikazani na slici 8.1. Može se uočiti kako tehnike Java RMI i ONC RPC stavljaju najmanje dodatnog podatkovnog troška na poziv udaljene metode/procedure, dok tehnika XML-RPC stavlja daleko najviše. To se objašnjava činjenicom da XML-RPC koristi enkapsulaciju poziva udaljene procedure, koji je predstavljen u XML formatu, unutar HTTP POST zahtjeva.

60

196

285229

186

288

830

494

0

50

100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900ok

teti

ONC RPC J2SE CORBA JacORBCORBA

Jav a/RMI DCOM XML-RPC .NET Remoting

Argument metode/procedure (12 znakova)

Slika 8.1: Količina podataka prenošena mrežom prilikom poziva udaljenje metode

posalji_poruku() s tekstualnim nizom od 12 znakova

Prijenos numeričkih podataka obrađen je detaljnije. Efikasnost pojedine tehnike uspoređena je na osnovi sljedećih svojstava:

- Vrijeme potrebno za spajanje klijenta na udaljeni objekt

- Prijenos različitog broja integer argumenata

- Prijenos polja byte brojeva varijabilne duljine

- Prijenos polja integer brojeva varijabilne duljine

- Prijenos polja double brojeva varijabilne duljine Na slici 8.2 prikazani su rezultati mjerenja spajanja klijenta na udaljeni objekt. Budući se kod tehnike ONC RPC radi o udaljenim procedurama, ovdje se mjerilo vrijeme spajanja na udaljeni program. Tehnika XML-RPC se ovdje nije razmatrala jer koristi stateless način komunikacije. Rezultati pokazuju da su DCOM i .NET Remoting najbrži prilikom spajanja, dok Java RMI zahtijeva najviše vremena zato što klijent prilikom prvog spajanja na udaljeni objekt mora dohvatiti stub klase poslužitelja kako bi preko njih pozivao udaljene metode. Kako razmatrani IRC klijent implementira klasu povratnog poziva, u ovom slučaju dohvaćanje stub klasa ide u oba smjera.

61

62 ms

32 ms47 ms

328 ms

16 ms 16 ms

0

50

100

150

200

250

300

350m

s

ONC RPC J2SE CORBA JacORB CORBA Jav a RMI DCOM .NET Remoting

Slika 8.2: Trajanje spajanja na udaljeni objekt/program

Performanse poziva udaljene metode su vrlo važne za visoko-zahtjevno mrežno računarstvo, gdje je vrijeme odziva važan faktor učinkovitosti. Za evaluiranje poziva udaljene metode korištene su metode s brojem integer argumenata od 1 do 5, te su rezultati prikazani na slici 8.3. Vidljivo je da je ONC RPC najbrži, dok su DCOM, Java RMI i .NET Remoting približno isti. J2SE CORBA, JacORB i XML-RPC vidno zaostaju.

0

0.5

1

1.5

2

2.5

1 2 3 4 5

broj argumenata

ms

ONC RPC J2SE CORBA JacORB CORBA Jav a RMI DCOM XML-RPC .NET Remoting

Slika 8.3: Trajanje prijenosa podataka prilikom poziva udaljene metode

Sustavi za prikupljanje podataka za razne svrhe poput ekperimenata u fizici ili prikupljanja procesnih podataka elektroenergetskog sustava zahtijevaju visoku

62

propusnost prijenosa numeričkih podataka, te je stoga zanimljivo istražiti kako se pojedine tehnike ponašaju u ovakvim situacijama. Kako bi se vrednovao prijenos numeričkih podataka, koristile su se tri metode koje primaju kao argument polje byte brojeva, integer brojeva i double brojeva. Broj elemenata polja je varijabilan, te je uzet interval (0, 100).

Slika 8.4 prikazuje rezultate prijenosa polja byte brojeva. Najbolje rezultate je pokazao ONC RPC, zatim slijede tehnike DCOM i Java RMI, dok evidentno najlošije performanse imaju J2SE CORBA i XML-RPC.

0

0.2

0.4

0.6

0.8

1

1.2

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

broj elemenata polja

ms

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

broj okteta


Slika 8.4: Prijenos polja byte brojeva

Kao što se vidi na slici 8.5, ONC RPC opet pokazuje najbolje rezultate i kod prijenosa polja integer brojeva. XML-RPC pokazuje najveći uspon iz razloga što koristi tehniku pakiranja svakog elementa polja unutar nove oznake (engl. tag), što dovodi do akumulirajućeg dodatnog vremenskog troška.

63

0

0.5

1

1.5

2

2.5

30 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100


ms

0 16 32 48 64 80 96 112

128

144

160

176

192

208

224

240

256

272

288

304

320

336

352

368

384

400

broj okteta


Slika 8.5: Prijenos polja integer brojeva

Slika 8.6 prikazuje ponašanje pojedinih tehnika prilikom prijenosa polja double brojeva. Vidi se da je i ovdje ONC RPC najbrži. Vremena ostalih tehnika sporo rastu, izuzevši XML-RPC koji se ponaša kao i kod prijenosa integer polja.

0

0.5

1

1.5

2

2.5

3

0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100


ms

0 32 64 96 128

160

192

224

256

288

320

352

384

416

448

480

512

544

576

608

640

672

704

736

768

800

broj okteta


Slika 8.6: Prijenos polja double brojeva

Može se zaključiti da je ONC RPC pokazao najbolja svojstva u svim kategorijama testova, dok je XML-RPC pokazao najmanje.

64

8.3.2. Stabilnost / prenosivost / lakoća programiranja Stabilnost, odnosno zrelost tehnologije može se učinkovito mjeriti vremenom zadržavanja pojedine tehnologije na tržištu. Ove činjenice navedene su u tablici 8.2.

Tablica 8.2: Pojavljivanje pojedine tehnike na tržištu

Tehnika Godina pojavljivanja

RPC 1988

CORBA 1991

Java RMI 1996

DCOM 1996

XML-RPC 1999

.NET Remoting 2002

Prenosivost se definira kao lakoća kojom se sustav ili komponenta može preseliti s jednog sklopovskog ili programskog okruženja na neko drugo. Detalji prenosivosti razmatranih tehnika raspodijeljenog programiranja prikazani su u tablici 8.3.

Tablica 8.3: Prenosivost pojedine tehnike

Tehnika Operacijski sustav / platforma Programski jezik

RPC

RPC predstavlja specifikaciju koja je navedena u nekoliko RFC (engl. Request For Comments) dokumenata što znači da se može izvoditi na bilo kojoj platformi za koju je implementirana RPC podrška, ali uglavnom se radi o UNIX platformama. Moguće je koristiti svaki programski jezik za koji postoji razvojna verzija RPC protokola.

C/C++ Java .NET porodica …

CORBA

Budući CORBA predstavlja specifikaciju, moguće ju je koristiti na svakoj platformi za koju je razvijena implementacija posrednika ORB. Isto vrijedi i za izbor programskog jezika, budući da taj izbor ovisi o postojanju biblioteka ORB posrednika za taj programski jezik.

C/C++ Java …

Java RMI

Može se izvoditi na svakoj platformi za koju postoji Java virtualni stroj. Budući se velikom mjerom oslanja na Java objektnu serijalizaciju, moguće je koristiti samo Java programski jezik.

Java

DCOM

Može se izvoditi na bilo kojoj platformi za koju postoji implementacija COM izvršnog okruženja. Kako se radi o specifikaciji na binarnoj razini, moguće je koristiti čitav niz programskih jezika.

C++ .NET porodica Java …

XML-RPC

Može se izvoditi na svakoj platformi za koju postoji implementacija protokola XML-RPC, a to znači večina platformi. Također, postoje implementacije u mnogim programskim jezicima.

C/C++ .NET porodica Java …

65

.NET Remoting

Budući.NET Remoting zahtjeva postojanje .NET radnog okruženja na platformi na kojoj se izvodi, trenutno ga samo operacijski sustav Microsoft Windows podržava. Moguće je koristiti bilo koji programski jezik koji se može prevesti u CIL (engl. Common Intermediate Language) izvorni tekst programa.

C# Visual Basic.NET C++.NET Delphi for .NET …

Lakoća programiranja se najjednostavnije može mjeriti količinom potrebnog izvornog teksta implementacije određene funkcionalnosti. Tablice 8.4 – 8.7 prikazuju izvorni tekst implementacija pojedinih segmenata IRC sustava korištenog kod testiranja efikasnosti.

Tablica 8.4: Definicija sučelja

Tehnika Izvorni tekst implementacije

RPC

program RPCIRC_PROG { version RPCIRC_VERS { void registriraj_callback(int)=1; void posalji_poruku(string)=2; void odjavi_callback(void)=3; }=1; }=0x20021016;

CORBA

module CORBAIRC { interface CORBAIRCCallback { void poruka_callback(in string poruka); }; interface CORBAIRCServerI { void registriraj_callback(in CORBAIRCCallback callbackClient); void posalji_poruku(in string poruka); void odjavi_callback(in CORBAIRCCallback callbackClient); }; };

Java RMI

Poslužitelj package JRMIIRC; import java.rmi.*; public interface JRMIIRCServerI extends java.rmi.Remote { void registriraj_callback(JRMIIRCCallback callbackClient) throws RemoteException; void posalji_poruku(String poruka) throws RemoteException; void odjavi_callback(JRMIIRCCallback callbackClient) throws RemoteException; } Klijent package JRMIIRC; import java.rmi.*; public interface JRMIIRCCallback extends java.rmi.Remote { void poruka_callback(String poruka) throws RemoteException; }

66

DCOM

import "oaidl.idl"; import "ocidl.idl"; [ object, uuid(4ED9E6AD-AB0F-4F93-B911-515A0EB19609), dual, helpstring("IDCOMIRCServerImpl Interface"), pointer_default(unique) ] interface IDCOMIRCServerImpl : IDispatch { [id(1), helpstring("method posalji_poruku")] HRESULT posalji_poruku([string] wchar_t *poruka); }; [ uuid(43CCE165-2922-4583-B502-D042391552F7), version(1.0), helpstring("DCOMIRCServer 1.0 Type Library") ] library DCOMIRCSERVERLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [ uuid(3A3A8AA6-8DBF-4AF1-8E0F-CAA645D545F0), helpstring("_IDCOMIRCServerImplEvents Interface") ] dispinterface _IDCOMIRCServerImplEvents { properties: methods: [id(1), helpstring("method poruka_callback")] HRESULT poruka_callback([string] wchar_t *poruka); }; [ uuid(9A64C80B-C8A9-461D-BA75-7507D3528565), helpstring("DCOMIRCServerImpl Class") ] coclass DCOMIRCServerImpl { [default] interface IDCOMIRCServerImpl; [default, source] dispinterface _IDCOMIRCServerImplEvents; }; };

XML-RPC Ne koristi se su elje

.NET Remoting

namespace General { public delegate void porukaEventDelegate(string poruka); public interface IREMOTIRCServer { event porukaEventDelegate porukaEvent; void posalji_poruku(string poruka); } }

67

Tablica 8.5: Instanciranje udaljenog objekta


RPC cl=clnt_create(argv[1], RPCIRC_PROG, RPCIRC_VERS, "tcp");

CORBA

java.util.Properties props=new java.util.Properties(); props.put("org.omg.CORBA.ORBInitialPort", "900"); props.put("org.omg.CORBA.ORBInitialHost", posluziteljTF.getText()); orb=ORB.init(new String[] {}, props); POA rootpoa=POAHelper.narrow( orb.resolve_initial_references("RootPOA")); NamingContextExt root=NamingContextExtHelper.narrow( orb.resolve_initial_references("NameService")); NameComponent[] name=new NameComponent[1]; name[0]=new NameComponent("CORBAIRCServer", ""); server=CORBAIRC.CORBAIRCServerHelper.narrow(root.resolve(name));

Java RMI server=(JRMIIRC.JRMIIRCServerI) Naming.lookup("rmi://"+posluziteljTF.getText()+ "/JRMIIRCServer");

DCOM hr=CoCreateInstance( CLSID_DCOMIRCServerImpl, NULL, CLSCTX_SERVER, IID_IDCOMIRCServerImpl, (void **) &server);

XML-RPC client=new XmlRpcClient("http://"+posluziteljTF.getText()+":5000/");

.NET Remoting

RemotingConfiguration.Configure("REMOTIRCClient.exe.config"); RemoteHelper remoteHelper=new RemoteHelper(); server=(IREMOTIRCServer) remoteHelper.getObject(typeof(IREMOTIRCServer));

Tablica 8.6: Registriranje procedure/metode povratnog poziva


RPC

SVCXPRT *xprt=svctcp_create(RPC_ANYSOCK); u_long tmp_prog=gettransient(IPPROTO_TCP, 1, xprt->xp_port); svc_register(xprt, tmp_prog, 1, poruka_callback_1, 0); registriraj_callback_1(&tmp_prog, cl); svc_run();

CORBA

callbackServer=new CORBAIRCCallbackImpl(this, orb); rootpoa.activate_object(callbackServer); callbackServerRef=CORBAIRC.CORBAIRCCallbackHelper. narrow(rootpoa.servant_to_reference(callbackServer)); server.registriraj_callback(callbackServerRef); rootpoa.the_POAManager().activate(); Thread callbackServerThread=new Thread(callbackServer); callbackServerThread.start();

Java RMI callbackServer=(JRMIIRC.JRMIIRCCallback) new JRMIIRCCallbackImpl("JRMIIRCCallback", this); server.registriraj_callback(callbackServer);

DCOM

IConnectionPointContainer *pCPC; IConnectionPoint *pCP; DWORD dwAdvise; hr=server->QueryInterface(IID_IConnectionPointContainer,

68

(void **) &pCPC); hr=pCPC->FindConnectionPoint(DIID__IDCOMIRCServerImplEvents, pCP); pCPC->Release(); callback=new CCallbackHandler(); IUnknown *pUnk=callback->GetIDispatch(FALSE); hr=pCP->Advise(pUnk, &dwAdvise); pCP->Release();

XML-RPC

WebServer callbackServer=new WebServer(4000); callbackServer.addHandler("CallbackHandler", new CallbackHandler(porukeTA)); callbackServer.start(); Vector params=new Vector(); params.addElement("http://"+ java.net.InetAddress.getLocalHost().getHostAddress()+ ":4000/"); client.execute("ServerHandler.registriraj_callback", params);

.NET Remoting

server.porukaEvent+=new porukaEventDelegate(new PorukaEvent(new porukaEventDelegate(server_porukaEvent)).server_porukaEvent);

Tablica 8.7: Slanje poruke poslužitelju


RPC posalji_poruku_1(&poruka, cl);

CORBA server.posalji_poruku(nadimakTF.getText()+": "+ porukaTA.getText());

Java RMI server.posalji_poruku(nadimakTF.getText()+": "+ porukaTA.getText());

DCOM

char *poruka=(char *) malloc(1024); char *porukaBody=(char *) malloc(1024); m_nadimakTB.GetLine(0, poruka); strcat(poruka, ": "); m_porukaTB.GetLine(0, porukaBody); strcat(poruka, porukaBody); USES_CONVERSION; hr=server->posalji_poruku(A2W(poruka));

XML-RPC Vector params=new Vector(); params.addElement(nadimakTF.getText()+": "+porukaTA.getText()); client.execute("ServerHandler.posalji_poruku", params);

.NET Remoting server.posalji_poruku(nadimakTB.Text+": "+porukaTB.Text);

Može se zaključiti kako su tehnike Java RMI i XML-RPC najjednostavnije za implementaciju raspodijeljenog sustava, ponajviše iz razloga što nije potrebno koristiti neki od jezika IDL za definiranje sučelja. S druge strane, DCOM je evidentno najkompliciraniji za implementaciju. Za detalje oko programiranja pojedinom tehnikom vidjeti [27], [6], [5], [8], [9], [15] i [16] (navedeno po redoslijedu opisa pojedine tehnike u ovom radu).

69

8.3.3. Sigurnost raspodijeljenog sustava Kriptografija je grana znanosti koja se, koristeći matematičke modele, bavi kriptiranjem i dekriptiranjem podataka. Kriptografija omogućava sigurnu pohranu i prijenos osjetljivih podataka preko nesigurnih mreža tako da sprječava čitanje poruke svakome osim onome komu je informacija namijenjena. U procesu kriptiranja i dekriptiranja koristi se kriptografski algoritam koji je zapravo neka matematička funkcija. Sigurnost kriptiranih podatka ovisi isključivo o snazi kriptografskog algoritma i tajnosti ključa. Kriptografski algoritmi, korišteni ključevi i protokoli zajedno sačinjavaju sustav kriptiranja ili sigurnosni sustav (engl. cryptosystem). Kriptiranje povjerljivih informacija prije prijenosa nesigurnim mrežama osigurava tajnost podataka. Podaci su kriptirani i ukoliko na neki način postanu dostupni neovlaštenim osobama još uvijek su nerazumljivi i kao takvi neupotrebljivi. Sigurna komunikacija osim tajnosti podataka još uključuje autentifikaciju, autorizaciju i očuvanje integriteta podataka. Autentifikacija podrazumijeva provjeru identiteta osoba, odnosno programskih sustava koji međusobno komuniciraju. Postupkom autentifikacije se utvrđuje da su sudionici komunikacije upravo oni za koje se izdaju. Opće prihvaćena definicija autorizacije opisuje ju kao postupak dodjeljivanja prava pristupa subjektima, koji mogu, na primjer, biti korisnici, programi ili procesi, onim dijelovima za koje imaju dozvolu. Autentifikacija i autorizacija su međusobno usko povezane, te predstavljaju tradicionalne tehnike računalne sigurnosti. Integritet poruka osobito je bitan u prijenosu podataka. Očuvanje integriteta poruke podrazumijeva sprječavanje mogućnosti zlonamjernog utjecaja na sadržaj poruke koja se prenosi. U nastavku će biti opisani osnovni modeli sigurne komunikacije u kriptografiji i načini na koji kriptografija osigurava zadovoljavanje prethodno navedenih svojstava sigurne komunikacije. Simetrična kriptografija. Simetrična kriptografija naziva se još i konvencionalna kriptografija. U simetričnoj kriptografiji koristi se isti ključ i za kriptiranje i za dekriptiranje podataka. Ovakav ključ naziva se sjednički ili simetrični ključ i moraju ga posjedovati i pošiljatelj i primatelj poruke. Prednost simetrične kriptografije leži u brzini procesa kriptiranja i dekriptiranja. Simetrična kriptografija osobito je pogodna za kriptiranje podataka koji se nigdje ne prenose. Problem simetrične kriptografije jest problem sigurne distribucije tajnog ključa. Kako bi pošiljatelj i primatelj mogli komunicirati moraju dogovoriti i razmijeniti tajni ključ. Ukoliko se nalaze na fizički odvojenim lokacijama javlja se problem sigurne razmjene ključeva između entiteta uključenih u razmjeni. Ukoliko neovlaštena osoba presretne tajni ključ u mogućnosti je čitati, modificirati i krivotvoriti originalne poruke. Asimetrična kriptografija. Problem sigurne razmjene ključeva riješen je korištenjem koncepta asimetrične kriptografije. Razlika od koncepta simetrične kriptografije je u tome što se u asimetričnoj kriptografiji koristi par ključeva: javni ključ i privatni ključ. Javni ključ koristi se za kriptiranje, dok se privatni ključ koristi za dekriptiranje podataka (i obrnuto – vidi digitalni potpis, poglavlje 8.3.7.). Javni ključ dostupan je svima i slobodno se distribuira, dok se privatni ključ čuva i drži se tajnim. Sve poruke kriptirane javnim ključem mogu biti dekriptirane isključivo pripadajućim privatnim ključem. Ovakvim načinom kriptiranja postiže se da poruku može dešifrirati samo onaj kojemu je ona upućena. Bitno svojstvo asimetrične kriptografije jest nemogućnost matematičkog izvođenja privatnog ključa iz poznatog privatnog ključa. Osnovna prednost korištenja javnog ključa jest eliminacija problema sigurne razmjene tajnih ključeva koji je postojao u

70

simetričnoj kriptografiji. Distribuiraju se javni ključevi, dok se tajni ključevi ne prenose, te nisu podložni mogućnosti presretanja. Hibridna kriptografija. Neki kriptografski sustavi koriste kombinaciju simetrične i asimetrične kriptografije. Ovakvi kriptografski sustavi nazivaju se hibridnim kriptografskim sustavima i objedinjuju dobre osobine simetričnih i asimetričnih kriptografskih sustava. Obično se prije postupka kriptiranja podaci koji se kriptiraju komprimiraju. Sažimanjem podataka, osim skraćivanja vremena prijenosa, postiže se i veća sigurnost podataka. Većina tehnika namijenjenih neovlaštenom dekriptiranju poruka bez korištenja ključa bazira se na pronalaženju ponavljajućih uzoraka u izvornom, nekriptiranom tekstu. Kompresijom se smanjuje broj ponavljajućih uzoraka, te se na taj način postiže veća otpornost prema neovlaštenom dekriptiranju. Sljedeći korak uključuje generiranje sjedničkog ključa (engl. session key). Sjednički ključ je tajni ključ koji se koristi jednokratno tijekom jedne sjednice, a predstavljen je slučajnim brojem generiranim na osnovu temelju slučajnih izvora kao što su pokreti miša i rad tipkovnice. Sjednički ključ koristi se kao tajni ključ za brzo i pouzdano simetrično kriptiranje izvornog podatka. Rezultat ove faze je kriptirani izvorni podatak. Zadnja faza postupka kriptiranja jest kriptiranje sjedničkog ključa korištenjem javnog ključa primaoca. Ovako kriptirani izvorni podatak i sjednički ključ zajedno se šalju primaocu. Dekriptiranje primljene poruke odvija se u suprotnom smjeru od procesa kriptiranja. Primatelj prvo dekriptira sjednički ključ korištenjem svog privatnog ključa. Nakon toga dobivenim sjedničkim ključem dekriptira kriptiranu poruku i dolazi do izvornog podatka. Korištenje kombinacije simetričnog i asimetričnog kriptiranja postiže se jednostavnost distribucije ključeva prisutna kod asimetrične kriptografije i brzina kriptiranja i dekriptiranja karakteristična za simetričnu kriptografiju. Simetrična kriptografija je oko 104 puta brža od asimetrične kriptografije. S druge strane, asimetrična kriptografija daje rješenje za jednostavnu i sigurnu razmjenu ključeva. Hibridni sustavi odlikuju se dobrim svojstvima i sigurnom distribucijom ključeva bez negativnih posljedica na sigurnost kao primarne zadaće. Digitalni potpis. Značajna prednost asimetrične kriptografije očituje se i mogućnošću korištenja digitalnih potpisa. Digitalni potpisi koriste se u svrhu potvrđivanja autentičnosti izvora i osiguranja integriteta prenošenih podataka. Također, njima je osigurana i neporecivost podataka. Sprječavanje nepriznavanja slanja poruke je osigurano, jer se pomoću digitalnog potpisa jednoznačno može odrediti tko je uputio poruku. Iz navedenog se vidi da digitalni potpisi imaju karakteristike i namjenu kao i klasični ručni potpisi, uz dodatnu funkciju očuvanja integriteta poruke i neporecivost podataka. Algoritam kreiranja digitalnog potpisa koristi kriptiranje privatnim ključem pošiljaoca. Ovako kriptirani podaci mogu se dešifrirati isključivo korištenjem pripadnog javnog ključa. Primatelj stoga koristi javni ključ pošiljaoca da bi potvrdio autentičnost poruke. Prethodno opisani postupak digitalnog potpisivanja dokumenta je relativno spor, a potpisani dokument je izrazito velik, najmanje dvostruko veći od izvornog dokumenta. Poboljšanje postupka digitalnog potpisivanja uključuje korištenje matematičkih metoda za sažimanje izvornog dokumenta. U tom postupku koristi se funkcija za izračunavanja sažetka poruke (hash funkcija). Funkcija za izračunavanja sažetka poruke je jednosmjerna funkcija koja ulaznu poruku varijabilne duljine transformira u niz bitova fiksne duljine. Navedena funkcija ima svojstvo da i najmanja promjena na

71

ulaznoj poruci rezultira promjenom u izlaznom nizu bitova. Rezultat fiksne duljine koji daje hash funkcija kriptira se privatnim ključem te se na taj način kreira digitalni potpis izvornog dokumenta. Kako se digitalni potpis generira nad fiksnom i relativno malom količinom podataka, postupak digitalnog potpisivanja znatno je brži od kriptiranja cijele poruke asimetričnim algoritmom. Digitalno potpisani rezultat funkcije za izračunavanje sažetka poruke zajedno s izvornim dokumentom prosljeđuje se primaocu. Primatelj koristeći javni ključ pošiljaoca potvrđuje autentičnost primljenog dokumenta. Na temelju primljenog dokumenta primatelj izračunava rezultat hash funkcije i uspoređuje ga s primljenim. Ukoliko su identični, prenošeni podaci nisu modificirani tijekom prijenosa. Dokle god se koristi sigurna hash funkcija ne postoji mogućnost modificiranja izvorne poruke, kao ni korištenje potpisa s jednog dokumenta uz neki drugi dokument. I najmanja promjena u izvornoj poruci uzrokuje negativan rezultat u postupku provjere digitalnog potpisa. Digitalni certifikat. Kod asimetrične kriptografije korisnici javnih ključeva moraju voditi računa da korišteni javni ključ uistinu pripada osobi, odnosno sustavu s kojim se želi komunicirati. U okruženju u kojem se slobodno distribuiraju javni ključevi postoji mogućnost da treća osoba, lažno se predstavljajući, podmetne krivotvoreni javni ključ, te na takav način dobije neovlašten pristup tajnim podacima. Stoga je veoma važno sa sigurnošću utvrditi pripadnost javnog ključa određenom entitetu, što u slučaju fizičke dislociranosti učesnika komunikacije ne predstavlja trivijalan problem. Kako bi se pojednostavnilo utvrđivanje valjanosti javnih ključeva, odnosno kako bi se utvrdila nedvosmislena povezanost javnog ključa i njegova vlasnika, koriste se digitalni certifikati. Digitalni certifikat sastoji se od javnog ključa, podataka certifikata kao što su ime i prezime korisnika, adresa elektroničke pošte i sl., te jednog ili više digitalnih potpisa. Digitalni potpisi služe kao potvrda da je valjanost podataka koji se nalaze u certifikatu potvrđena od strane nezavisnog entiteta. Najpoznatiji format digitalnog certifikata poznat je pod nazivom X.509. Postoji nekoliko organizacija koje izdaju potvrđene digitalne certifikate. Digitalni certifikati potvrđeni od ovih organizacija smatraju se valjanima. Neke organizacije imaju vlastiti sustav izdavanja digitalnih certifikata kako bi bili u mogućnosti autentificirati svoje zaposlenike, mrežne uređaje i druge entitete uključene u razmjenu podataka. Postoji i mogućnost samo-potpisivanja digitalnih certifikata. U tom slučaju, određeni entitet potpisivanjem digitalnog certifikata vlastitim privatnim ključem jamči za valjanost svog javnog ključa. Ovakav princip predstavlja najjednostavniji način kreiranja digitalnih certifikata u samostojećim sustavima. SSL/TSL komunikacijski protokol. SSL (engl. Secure Sockets Layer) protokol je najrašireniji protokol koji podržava sigurnu komunikaciju HTTP protokolom u nesigurnim mrežama poput globalne mreže Internet. Može se koristiti i za druge protokole aplikacijskog nivoa kao što su SMTP, FTP i sl. SSL protokol omogućava autentifikaciju, kako klijenta tako i poslužitelja, tajnost podataka, te osiguranje integriteta podataka, pri čemu koristi hibridni model kriptiranja opisan u 8.3.6. SSL protokol razvila je korporacija Netscape Communications Corporation 1994. godine. Nedugo nakon toga IETF (engl. Internet Engeenering Task Force) radi na standardizaciji protokola temeljenog na SSL protokolu. Ovakav standardizirani protokol naziva se TLS (engl. Transport Layer Security) protokol. SSL i TLS protokol imaju mnogo sličnosti pa se u literaturi obično tretiraju kao da se radi o istom protokolu.

72

Sloj SSL protokola nalazi se između aplikacijskog sloja i transportnog sloja, te se može koristiti u kombinaciji s različitim protokolima aplikacijskog sloja. SSL protokol sastoji se od dva podprotokola: protokol uspostave veze (engl. handshake protocol) i protokol prijenosa podataka (engl. record protocol). Protokol uspostave veze opisuje postupak inicijalizacije sesije i uključuje međusobnu autentifikaciju sudionika komunikacije, dogovor oko korištenog algoritma kriptiranja, te razmjenu ključeva koji će se koristiti u komunikaciji koja će uslijediti nakon inicijalizacije veze. Postupak uspostave veze obavlja se u sljedećim koracima:

1. Klijent poslužitelju šalje poruku koja se sastoji od korištene verzije SSL protokola, slučajno generiranog broja, identifikatora sjednice (ako se želi nastaviti prethodno inicirana sjednica), skupa algoritama kriptiranja i algoritma kompresije.

2. Poslužitelj klijentu šalje iste podatke kao klijent poslužitelju. 3. Poslužitelj klijentu šalje svoj digitalni certifikat kojega klijent

autentificira. Ukoliko proces autentifikacije ne bude uspješan klijent prekida postupak uspostave veze.

4. Opcionalno poslužitelj može tražiti autentifikaciju od klijenta, ili mu poslati privremeni ključ koji će klijent koristiti u narednom koraku. Privremeni ključ se koristi ukoliko digitalni certifikat poslužitelja ne sadrži javni ključ.

5. Ukoliko je poslužitelj zahtijevao autentifikaciju klijenta, klijent šalje svoj digitalni certifikat u kojemu se nalazi i njegov javni ključ.

6. Koristeći generirane slučajne brojeve klijent generira tzv. premaster ključ, kriptira ga javnim ključem poslužitelja, te ga prosljeđuje poslužitelju. Koristeći spomenuti ključ klijent i poslužitelj lokalno generiraju sjednički ključ.

7. Ukoliko je poslužitelj od klijenta zahtijevao slanje certifikata, klijent u ovom trenutku mora poslati i digitalno potpisan rezultat hash funkcije svih do sada izmijenjenih poruka.

8. Klijent šalje potvrdu da će sve sljedeće poruke biti kriptirane dogovorenim ključevima i algoritmima. Na kraju klijent šalje poruku da je završio sa slanjem poruka.

9. Poslužitelj šalje poruku kojom obavještava klijenta da će sve sljedeće poruke biti kriptirane dogovorenim ključevima i algoritmima, te šalje poruku kojom zaključuje uspostavu veze.

Nakon uspješne uspostave veze i dogovora oko korištenih algoritama i ključeva sigurna komunikacija može otpočeti. Za slanje kriptiranih podataka aplikacijskog nivoa koristi se SSL protokol prijenosa podataka.

8.3.4. Usporedba sigurnosnih mehanizama raspodijeljenih tehnika Raspodijeljene tehnike se uglavnom ograničavaju na podršku autentifikacije i autorizacije [43]. Tablica 8.5 prikazuje sažetak sigurnosnih obilježja razmatranih tehnika, dok je detaljniji opis sigurnosnih impementacija pojedine tehnike dan u posebnom poglavlju vezanom uz određenu tehniku.

73

Tablica 8.5: Sigurnosna obilježja pojedine tehnike

Tehnika Sigurnost

RPC RPC protokol definira samo autentifikaciju. Autorizacija mora biti riješena korisnički.

CORBA CORBA sigurnosna usluga pruža kompletno radno okruženje za sigurnost raspodijeljenih objekata. Podržava autentifikaciju, autorizaciju i neporecivost.

Java RMI Usluga Java Authentication and Authorization Service (JAAS) pruža moćan mehanizam autentifikacije i autorizacije koji podržava sigurnosne sustave Windows NT, UNIX, Kerberos, Keystore i dr.

DCOM

DCOM pruža jedan od najnaprednijih i najkompliciranijih modela sigurnosti primijenjen u raspodijeljenim sustavima. DCOM sigurnost je usko vezana uz Windows NT sigurnost što pruža niz prednosti pred ostalim operacijskim sustavima budući je NT sigurnost fundamentalni dio operacijskog sustava. Autentifikacija i autorizacija su, naravno, podržani.

XML-RPC

Protokol XML-RPC ne definira sigurnosne mehanizme, ali budući koristi HTTP kao prijenosni protokol moguće je iskorištavanje njegovih sigurnosnih svojstava. Također je moguće koristiti protokol SSL/TLS za sigurni prijenos podataka što ovisi o samoj implementaciji protokola XML-RPC.

.NET Remoting

Autentifikacija i autorizacija je indirektno riješena prilikom korištenja sustava IIS kao aktivacijskog agenta, dok je u suprotnom potrebno implementirati korisnički definirane ponore i pružatelje ponora s adekvatnom sigurnosnom funkcionalnošću.

74

9. Raspodijeljeno programiranje u okruženju zaštićenim sigurnosnom stijenom

9.1. Uvod

Sigurnosne stijene predstavljaju komponente koje štite skup sredstava ograničavajući mrežni pristup. One imaju mogućnost nametanja ograničenja zasnovanih na izvoru ili odredištu prometa ili na vrsti korištenog protokola. Međutim, ograničenja također mogu biti specifična prema pojedinoj aplikaciji. U slučaju da su ispravno administrirane, sigurnosne stijene mogu pružiti samo određenu razinu zaštite. Stoga, nije preporučljivo iskjučivo se oslanjanje na njih u korist sveobuhvatne zaštite u okruženjima gdje je sigurnost i zaštita podataka od iznimne važnosti. Sigurnosne stijene stvaraju složene probleme raspodijeljenim aplikacijama čije je djelovanje prošireno na Internet. Opći scenarij je prikazan na slici 9.1. Objekti na strani poslužitelja su zaštićeni ulaznim sigurnosnim stijenama, dok se klijenti mogu nalaziti iza izlaznih sigurnosnih stijena. Valja napomenuti da veće organizacije mogu upotrebljavati više razina ugniježđenih sigurnosnih stijena na obje strane.

Slika 9.1: Opći scenarij zaštite sigurnosnom stijenom

Sigurnosna stijena na strani klijenta ili izlazna sigurnosna stijena se obično postavlja od strane poduzeća s ciljem restrikcije pristupa Internetu zaposleniku. Jedan od razloga za ovo je onemogućavanje korištenja nesigurnih vanjskih usluga ili skrivanje internih adresa računala. Pružatelji usluga pristupa Internetu također mogu imati postavljene sigurnosne stijene u nekim slučajevima. Oni obično ograničavaju pristup Internetu svojim pretplatnicima na samo određene protokole, poput protokola HTTP i NNTP. Moguće je postojanje i dodatnih restrikcija, kao na primjer NNTP pristupnika koji dozvoljava pristup samo odabranim USENET grupama. Sigurnosna stijena na strani poslužitelja ili ulazna sigurnosna stijena je postavljena kako bi ograničila vanjski pristup internim sredstvima. Ulazne i izlazne sigurnosne stijene za zajednicu mogu biti konfigurirane za rad na istom sklopovlju ili čak u istom procesu, ali one su funkcionalno nezavisne te se stoga mogu i razdvojiti.

75

9.2. Vrste sigurnosnih stijena

Sigurnosne stijene funkcioniraju korištenjem različitih mehanizama od kojih su najčešći filtriranje paketa bazirano na podacima prijenosnog nivoa, koje ne zahtjeva od sigurnosne stijene razumijevanje sadržaja paketa, te filtriranje bazirano na aplikacijskim podacima, što zahtjeva interpretaciju paketa. U nastavku su objašnjena oba mehanizma.

9.2.1. Filtriranje paketa Filtriranje paketa je moguće izvršavati na različitim razinama sloga protokola. Odluke se donose ovisno o podacima unutar zaglavlja paketa. U najjednostavnijem slučaju, kada se filtriranje obavlja na IP razini, sigurnosne stijene baziraju svoje odluke na izvorišnim i odredišnim adresama IP paketa i usko su povezane uz usmjerivače. Kako bi implementirala određenu politiku, sigurnosna stijena postavlja ograničenja na usmjerivaču. Potrebno je napomenuti da su mrežna ograničenja nametnuta preglednicima na applet-e u principu samo instance vrlo jednostavnog izlaznog filtra paketa koji zabranjuje sve pristupe prema van osim prema poslužitelju applet-a. Sadašnje sigurnosne stijene uglavnom funkcioniraju na prijenosnoj razini, što implicira da se izvor i odredište paketa može opisati pomoću IP adresa individualnih računala i/ili podmreža, vrste prijenosa (TCP, UDP) i TCP ili UDP brojeva pristupa. Slika 9.2 prikazuje mehanizam sigurnosne stijene na razini filtriranja paketa.

Slika 9.2: Filtrirajuća sigurnosna stijena na razini paketa

Ovakve sigurnosne stijene obično dozvoljavaju politike izražene pravilima poput sljedećih:

- Dozvoli sve vrste paketa, ali samo do određene IP adrese i određenog pristupa.

- Dozvoli ulazni promet samo od određenih podmreža. - Dozvoli samo UDP promet do određene IP adrese i određenog pristupa.

76

- Dozvoli TCP promet određenog izvorišnog opsega pristupa do određene podmreže.

Ova shema funkcionira za svaki protokol razvijen povrh TCP-a, te je stoga primjenjiva na protokole na "žici" raspodijeljenih tehnika koje koriste protokol TCP kao prijenosni sloj. Kako bi se omogućila suradnja između raspodijeljene aplikacije i ulaznih i izlaznih sigurnosnih stijena, poslužitelji se moraju izvršavati na specifičnim pristupima prihvaćenim od strane svih filtera paketa. Ponekad je potrebno učiniti filtre paketa propusnim za promet vezan uz raspodijeljene aplikacije. Odredišne IP adrese i brojevi pristupa moraju biti dozvoljeni na filtrirajućim sigurnosnim stijenama, pogotovo u slučaju kad su klijenti aplikacije u istoj organizaciji kao i poslužitelj. Tada se politika za sigurnosnu stijenu na strani klijenta, potrebna za ispravan rad poslužitelja, može dogovoriti s administratorima sustava. Ovo se može proširiti na situacije gdje organizacije imaju klijente na više lokacija te koriste Internet za njihovu međusobnu komunikaciju. Ostale organizacije koje pružaju uslugu konačnom skupu poznatih korisnika mogu zahtijevati od korisnika da promijene svoju politiku sigurnosne stijene na strani klijenta. Glavni razlog zbog čega se ne bi trebalo ekskluzivno oslanjati na sigurnosne stijene filtriranja paketa za kontroliranje pristupa sredstvima je nepouzdanost informacija na kojima se baziraju odluke filtriranja. Paketi i veze obično nisu autentificirane, a mrežne adrese i brojeve pristupa, unutar IP i TCP zaglavlja, je moguće krivotvoriti od strane vještog napadača. Stoga, dozvola prolaza paketima zasnovano na njihovim odredišnim adresama može zaustaviti samo jednostavne napade. Nepostojanje autentifikacije i kriptiranja u nižim slojevima sloga protokola dovelo je do definicije Internet norme pod nazivom IP Security Protocol (IPSec). Moguće ju je koristiti s obje verzije IP protokola, IPv4 i IPv6. Prema tome, jedini način na koji sigurnosne stijene mogu donositi pouzdane odluke je u slučaju da se autentifikacija obavlja u višim slojevima.

9.2.2. Pristupnici na aplikacijskoj razini Jednostavni filtri paketa ostavljaju neinterpretiranim aplikacijski sadržaj paketa. Za razliku od njih, sigurnosne stijene na aplikacijskoj razini interpretiraju taj sadržaj te ovisno o interpretaciji donose odluke. Prema tome, programska oprema koja se izvršava na sigurnosnoj stijeni mora moći razumjeti individualne protokole. Sigurnosne stijene mogu biti instalirane na jednostrukom računalu "bedemu" koji upravlja svim funkcijama sigurnosne stijene, ili može postojati skup računala i programa koji međusobno raspodjeljuju posao i obrađuju različite individualne protokole na različitim računalima. Sigurnosne stijene pristupnici su obično kombinirane s filtrima paketa tako da predstavljaju jedina računala unutar zaštićene domene do kojih je moguće pristupiti izvana. Jedna od mogućih kombinacija je prikazana na slici 9.3.

77

Filter paketa

TCP

Gateway G

XY protokol

Sigurnosna stijenaRačunalo H

XY aplikacija

internieksterni

a) do G:port1

b) do G:port1

c) do H:port4

XY promet

ne-XY promet

Slika 9.3: Sigurnosne stijene pristupnici

Vanjski pristup zajednici je ograničen filtrom paketa koji blokira cijeli ulazni promet osim paketa adresiranih na pristupnika G. Također, računalo H nije direktno pristupno. Prema slici 9.3, pristupnik obrađuje samo protokol XY i odbacuje sve poruke ostalih protokola. Kako bi se dozvolila komunikacija XY između računala H i vanjskog svijeta, pristupnik mora imati sposobnost mapiranja ulaznog prometa na interna računala što ovisi o mogućnostima obrađivanog protokola. Sigurnosne stijene pristupnici su obično konfigurirane tako da se ponašaju kao zamjenski poslužitelj (engl. proxy server), te se ponekad termini zamjenski poslužitelj i pristupnik međusobno izmjenjuju. Zamjenski poslužitelj je pristupnik koji se ponaša kao klijent prema poslužitelju i kao poslužitelj prema klijentu, štiteći na taj način svaku krajnju točku komunikacije od direktnog kontakta s drugom točkom. Također, takav pristupnik skriva stvarne adrese krajnjih točaka. Pristupnici također mogu ponekad funkcionirati u pass-through načinu rada tako da se klijentima i poslužiteljima čini da komuniciraju direktno. Obično, sigurnosne stijene, koje se ponašaju kao zamjenski poslužitelj, dolaze s HTTP, FTP, NNTP i SMTP pristupnicima. Popularna tehnologija za razvoj TCP sigurnosne stijene, koja se ponaša kao zamjenski poslužitelj, je biblioteka NEC SOCKS, koja se također može koristiti pri implementaciji sigurnosnih stijena koje autentificiraju veze.

78

9.3. Raspodijeljene tehnike i sigurnosne stijene

9.3.1. Problem zaobilaženja sigurnosne stijene S obzirom na dinamičku prirodu tehnika raspodijeljenog programiranja, teško je ili čak nemoguće konfigurirati standardne sigurnosne stijene filtriranja paketa, i ulazne i izlazne, za propuštanje toka poruka bez istovremenog dozvoljavanja proizvoljnog pristupa mreži. Naprosto otvaranje potrebnog opsega pristupa obično nije dostatno jer, ovisno o raspodijeljenoj tehnici, nije isključeno da se unaprijed ne znaju svi potrebni brojevi pristupa. Potvrda ovome je činjenica da je uobičajeno za klijent programe da stvaraju reference na objekte i prosljeđuju ih poslužitelju za povratne pozive. Statički konfigurirane sigurnosne stijene ne dozvoljavaju izvršavanje ovakvih povratnih poziva. U većini slučajeva, jednostavno otvaranje dodatnih pristupa za ulazni TCP promet se također smatra previše tolerantnim s obzirom na lokalne sigurnosne politike. U nastavku su ukratko prezentirana tri načina rješavanja problema koje nameću ulazne i izlazne sigurnosne stijene.

9.3.2. HTTP tuneliranje Uobičajen pristup zaobilaženja ograničenja nametnutih izlaznim sigurnosnim stijenama je HTTP tuneliranje. Izlazne sigurnosne stijene su obično postavljene kako bi onemogućile korištenje vanjskih usluga koje se smatraju nesigurnim od strane lokalnih administratora, ali uglavnom dopuštaju HTTP veze. HTTP tuneliranje ima značenje enkapsuliranja zahtjeva u HTTP omotnicu i slanje putem HTTP protokola. Primajući HTTP poslužitelj mora imati mogućnost razumijevanja ovih specijalnih HTTP zahtjeva. Njegov zadatak je izdvojiti zahtjev određene raspodijeljene tehnike iz HTTP omotnice i izvršiti stvarni zahtjev nad ciljnim objektima. Slika 9.4 prikazuje ideju HTTP tuneliranja.

Slika 9.4: HTTP tuneliranje

Ovakav pristup podbacuje kod integriranja tehnika raspodijeljenog programiranja s uobičajenim sigurnosnim stijenama i pruža samo na strani klijenta rješenje za ograničenja nametnuta preglednicima i izlaznim sigurnosnim stijenama. Neki od ozbiljnijih problema ove tehnike su:

- Neefikasnost tehnike koja proizlazi iz potrebe za pakiranjem i raspakiranjem podataka specifičnih za protokol raspodijeljene tehnike u i iz podataka HTTP protokola. Zatim iz potrebe za redirekcijom od konačnog HTTP poslužitelja na pravog poslužitelja udaljenih objekata te iz povećanog broja otvorenih TCP veza budući svaki HTTP zamjenski poslužitelj unutar lanca zamjenskih poslužitelja mora inicirati novu TCP vezu sa sljedećim zamjenskim poslužiteljem ili konačnim ciljem (za svaki poziv udaljene metode) za razliku od izravne klijent-poslužitelj komunikacije

79

gdje se zadržava ista TCP veza za uzastopne pozive unutar intervala isteka valjanosti veze.

- Neke tehnike poput tehnike Java RMI implementiraju HTTP tuneliranje kao rezervni način komunikacije u slučaju da direktna veza ne uspije, što nameće dodatno vrijeme izvršavanja na svaku novu klijent vezu.

- Povratni pozivi poslužitelja nisu podržani.

9.3.3. Zamjenski poslužitelj U slučaju da se koristi zamjenski poslužitelj prilagođen određenoj raspodijeljenoj tehnici, klijent će svu svoju komunikaciju obavljati sa zamjenskim poslužiteljem koji će pozive klijenta prosljeđivati kroz sigurnosnu stijenu u originalnom obliku ili enkapsulirane unutar nekog drugog protokola, kao na primjer protokola HTTP. Sigurnosna stijena mora biti konfigurirana da propušta prema van određenu vrstu komunikacije. Prema unutra, sigurnosna stijena mora propustiti određeni protokol do zamjenskog poslužitelja raspodijeljene tehnike, te na taj način je omogućen mehanizam povratnog poziva poslužitelja. Slika 9.5 prikazuje scenarij komunikacije preko zamjenskog poslužitelja.

Povratni pozivPoziv Po

ziv

Povra

tni po

ziv

Slika 9.5: Zamjenski poslužitelj prilagođen određenoj raspodijeljenoj tehnici

Za primjere implementacije zamjenskog poslužitelja raspodijeljene tehnike vidjeti [41] i [42].

9.3.4. Dvosmjerni komunikacijski kanal Najučinkovitije rješenje problema komunikacije u okruženjima zaštićenim sigurnosnom stijenom predstavlja iskorištavanje već postojeće TCP veze za pozive udaljenih metoda na strani i klijenta i poslužitelja, a prikazano je na slici 9.6.

80

Slika 9.6: Dvosmjerni komunikacijski kanal

Iako ovakav pristup dozvoljava povratne pozive, on ima nekoliko ozbiljnih sigurnosnih implikacija, tj.:

- Budući se ponovno koristi već postojeći prijenosni i sigurnosni kontekst, klijent ne posjeduje način na koji može zahtijevati dodatnu autentifikaciju poslužitelja povrh one provedene tijekom uspostavljanja veze. Također, klijent ne može odbaciti zahtjeve poslane preko ove veze ne prihvaćanjem veze jer bi se time onemogućila dvosmjerna komunikacija.

- Poslužitelj ne posjeduje način na koji može provjeriti informacije protokola dostavljene od klijenta koje definiraju gdje treba poruke slati. To znači da zlonamjeran klijent može prevariti poslužitelja i navesti ga na slanje svojih zahtjeva za povratnim pozivima na proizvoljnu lokaciju.

CORBA specifikacija navodi dvosmjerni komunikacijski kanal u obliku tzv. dvosmjernog protokola GIOP, a praktična uporaba ovog rješenja se može vidjeti u [39].

81

10. Dvosmjerni .NET Remoting komunikacijski kanal

10.1. Uvod

Implementacije prijenosnih kanala prisutne u .NET radnom okruženju pružaju potporu za razmjenjivanje .NET Remoting poruka na nivou transportnog sloja, odnosno TCP sloja, i aplikacijskog sloja enkapsulacijom u HTTP protokol. Oba komunikacijska kanala podliježu nedostacima opisanim u poglavljima 9.3.1. i 9.3.2. Ukratko, ako pretpostavimo da se klijent nalazi s unutarnje strane sigurnosne stijene te je zaštićen od vanjskog svijeta, a poslužitelj s vanjske strane sigurnosne stijene, onda klijent nije u mogućnosti primati obavijesti (engl. notification) odnosno povratne pozive od strane poslužitelja. Razlog tome je što poslužitelj, da bi pozvao udaljenu proceduru klijenta, koristi isti način uspostavljanja komunikacijskog kanala kao i klijent. U toj situaciji klijent i poslužitelj mijenjaju uloge te klijent sada postaje poslužitelj, a poslužitelj postaje klijent. Kako prilikom uspostavljanja novog komunikacijskog kanala poslužitelj pokušava otvoriti novu TCP vezu s klijentom, taj pokušaj će završiti na sigurnosnoj stijeni koja će zaustaviti otvaranje veze. U ovom poglavlju prezentirana je predložena implementacija rješenja navedenog problema, koja predstavlja dvosmjerni komunikacijski kanal te se poziva na ideje iznesene u poglavlju 9.3.4. Za detalje vezane uz mrežno programiranje u .NET-u vidjeti [21], dok je pregled .NET-a na nižoj razini naveden u [14].

10.2. Implementacija dvosmjernog kanala

10.2.1. Klase za komunikaciju između klijenta i poslužitelja .NET radno okruženje pruža velike mogućnosti prilagođavanja Remoting infrastrukture. Osnovne klase koje izravno sudjeluju u komunikaciji između klijenta i poslužitelja su:

- Klasa koja implementira kanal - Implementira sučelje IChannel, te u slučaju da predstavlja klijentsku stranu implementira sučelje IChannelSender, odnosno ako predstavlja poslužiteljsku stranu IChannelReceiver sučelje. Ako klasa kanala mora podržavati funkcije i klijenta i poslužitelja, tada ona mora implementirati oba sučelja. Ova klasa predstavlja oklop cijelog komunikacijskog procesa.

- Klasa koja implementira pružatelja ponora – Na strani klijenta, klasa implementira sučelje IClientChannelSinkProvider, dok na strani poslužitelja sučelje IServerChannelSinkProvider.

- Klasa koja implementira ponor – Ako klasa obrađuje sam objekt poruke, onda implementira sučelje IMessageSink, dok u slučaju da obavlja operacije nad serijaliziranom porukom u obliku toka podataka implementira sučelje IClientChannelSink, ako je riječ o strani klijenta, odnosno IServerChannelSink, ako je riječ o strani poslužitelja.

82

10.2.2. Struktura poruke prijenosnog kanala Slika 10.1 prikazuje strukturu poruke implementiranog dvosmjernog kanala na razini toka podataka prenošenog mrežom.

Poruka

Prijenosnozaglavlje

Duljina prijenosnog

zaglavlja

Duljina poruke

0 .. 1

m .. m+3

2 .. m-1

m+4 .. n-1

oktet oktet

Slika 10.1: Format poruke

- Duljina prijenosnog zaglavlja – Podatak veličine dva okteta koji definira duljinu prijenosnog zaglavlja, koje slijedi, u obliku broja okteta.

- Prijenosno zaglavlje – Serijalizirani oblik zaglavlja vezanog uz pojedinu poruku.

- Duljina poruke – Podatak veličine četiri okteta, a predstavlja broj okteta serijalizirane poruke koja slijedi.

10.2.3. Arhitektura kanala Implementacija dvosmjernog .NET Remoting komunikacijskog kanala sastoji se od sljedećih klasa:

- BidirectTCPClientChannel – Glavna klasa na strani klijenta koja implementira sučelja IChannelSender i IChannelReceiver.

- BidirectTCPClientTransportSink – Prijenosni ponor koji se nalazi na kraju lanca ponora klijentske strane. Ova klasa implementira sučelje IClientChannelSink.

- BidirectTCPClientTransportSinkProvider – Pružatelj prijenosnog ponora na strani klijenta koji implementira sučelje IClientChannelSinkProvider.

- BidirectTCPServerChannel – Glavna klasa na strani poslužitelja koja implementira sučelja IChannelReceiver i IChannelSender.

- BidirectTCPServerTransportSink – Prijenosni ponor koji se nalazi na početku lanca ponora poslužiteljske strane. Ova klasa implementira sučelje IServerChannelSink.

- BidirectTCPTransportHandler – Implementacija komunikacijskog kanala na TCP nivou, odnosno prijenosni rukovatelj.

83

- BidirectTCPListener – Implementacija slušatelja zahtjeva za vezom na strani poslužitelja koja pokreće uspostavljanje veze.

- BidirectTCPMessage – Enkapsulacija serijalizirane poruke i prijenosnog zaglavlja u posebnom objektu.

- BidirectTCPChannelHelper – Kolekcija statičkih metoda korištenih u raznim klasama.

Slika 10.2 prikazuje sadržaj primjera konfiguracijske datoteke dvosmjernog kanala na strani klijenta.

<configuration> <system.runtime.remoting> <application> <client> <wellknown type="DemoService.DemoObject, DemoService" url="btcp://192.168.0.203:1234/DemoObject" /> </client> <client url="btcp://192.168.0.203:1234"> <activated type="DemoService.DemoObject1, DemoService" /> </client> <channels> <channel type="BidirectTCPChannel.BidirectTCPClientChannel, BidirectTCPChannel" callback="yes"> <clientProviders> <formatter ref="binary" /> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>

Slika 10.2: Konfiguracijska datoteka klijenta

Nakon što se učita ova konfiguracijska datoteka, stvori se lanac pružatelja ponora koji se sastoji od objekata prikazanih na slici 10.3.

BinaryClientFormatterSinkProvider

BidirectTCPClientTransportSinkProvider

Next

BidirectTCPClientChannel

_clientSinkProvider

Slika 10.3: Lanac pružatelja ponora na strani klijenta

Na slici 10.4 naveden je sadržaj primjera konfiguracijske datoteke dvosmjernog kanala na strani poslužitelja.

<configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="DemoService.DemoObject, DemoService" objectUri="DemoObject" />

84

<activated type="DemoService.DemoObject1, DemoService" /> </service> <channels> <channel type="BidirectTCPChannel.BidirectTCPServerChannel, BidirectTCPChannel" port="1234" callback="yes"> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> </application> <customErrors mode="Off" /> </system.runtime.remoting> </configuration>

Slika 10.4: Konfiguracijska datoteka poslužitelja

Na slici 10.5 vidi se rezultat učitavanja ove konfiguracijske datoteke.

Slika 10.5: Lanac pružatelja ponora na strani poslužitelja

Stvaranje ponora na strani poslužitelja funkcionira na nešto drugačiji način od stvaranja ponora na strani klijenta, gdje se potrebni ponori stvaraju prilikom dohvata reference na udaljeni objekt. Suprotno ovome, ponori na strani poslužitelja se stvaraju prilikom registracije kanala.

Ako se u konfiguracijskoj datoteci unutar bloka <channel> postavi vrijednost atributa callback na "yes", kanal tada predstavlja dvosmjerni prijenosni put te se na strani klijenta uz inicijalni lanac pružatelja ponora instancira i lanac pružatelja ponora za posluživanje zahtjeva. S druge strane, kod poslužitelja se također generira i lanac pružatelja ponora za pozivanje udaljenih metoda. Ovaj scenarij je potreban iz razloga što i klijent i poslužitelj tada igraju obje uloge, odnosno poslužitelj mora imati mehanizam povratnog poziva metode klijenta dok klijent mora imati mogućnost posluživanje takvih zahtjeva. Na slici 10.6 prikazana je arhitektura dvosmjernog .NET Remoting komunikacijskog kanala.

85

Slik

a 10

.6: A

rhite

ktur

a dv

osm

jern

og .N

ET R

emot

ing

kom

unik

acijs

kog

kana

la

86

Prilikom instanciranja udaljenog objekta na strani klijenta, stvara se zamjenski objekt koji pokazuje na lanac ponora. Za svaku instancu udaljenog objekta postoji po jedan zaseban lanac ponora. Ti lanci ponora završavaju objektom klase BidirectTCPClientTransportSink koji je povezan s odgovarajućim prijenosnim rukovateljem. Postoji po jedan prijenosni rukovatelj za svaku kombinaciju klijent – poslužitelj na obje strane. Na strani klijenta, prijenosni kanal je identificiran kombinacijom IP adrese poslužitelja i broja pristupa na kojem poslužitelj osluškuje zahtjeve. Ovaj podatak nije dostatan za identifikaciju prijenosnog rukovatelja na strani poslužitelja iz razloga što ako se klijent nalazi iza sigurnosne stijene, velika je vjerojatnost da je njegova IP adresa privatna i skrivena mehanizmom NAT (engl. Network Address Translation). Stoga se koristi identifikator clientEndPointId generiran od strane poslužitelja prilikom uspostavljanja veze s klijentom, koji je jedinstven unutar procesa poslužitelja. Taj identifikator se šalje klijentu te se kasnije koristi u slučaju potrebe ponovnog uspostavljanja veze. Za posluživanje zahtjeva i pozivanje metoda udaljenih objekata, generira se samo jedan lanac ponora po kanalu. Svi prijenosni rukovatelji pokazuju na isti objekt klase BidirectTCPServerTransportSink, te sve zahtjeve prosljeđuju tom objektu.

10.2.4. Inicijalizacija veze na strani klijenta Nakon što je stvoren zamjenski objekt, kojeg proces klijenta vidi kao pravi udaljeni objekt, on sadrži referencu na lanac ponora koji završava objektom klase BidirectTCPClientTransportSink. Unutar konstruktora ovog objekta provjerava se da li već postoji instancirani prijenosni rukovatelj koji upravlja komunikacijom s ciljnim poslužiteljem identificiranim nizom "ip poslužitelja:pristup". Ako postoji, onda je taj prijenosni rukovatelj dodijeljen prijenosnom ponoru, dok u suprotnom slijedi instanciranje novog prijenosnog rukovatelja, odnosno objekta klase BidirectTCPTransportHandler. Programski odsječak implementacije prikazan je na slici 10.7.

if (_clientChannel.TransportHandlers[_serverIPAddress.ToString()+ ":"+_serverPort.ToString()]==null) { _clientTHandler=new BidirectTCPTransportHandler( _serverIPAddress, _serverPort, clientChannel.ServerTransportSink, null, 0); lock (_clientChannel.TransportHandlers) { _clientChannel.TransportHandlers.Add( _serverIPAddress.ToString()+":"+_serverPort.ToString(), _clientTHandler); } _clientChannel.LocalPort=_clientTHandler.LocalPort; ArrayList channelUris=new ArrayList(); channelUris.AddRange(new string[] {"btcp://"+ _clientTHandler.ClientEndPointId.ToString()}); if (_clientChannel._channelData.ChannelUris!=null) channelUris.AddRange( _clientChannel._channelData.ChannelUris); _clientChannel._channelData.ChannelUris=(string[]) channelUris.ToArray(typeof(string)); _clientTHandler.notifyClientClosingEvent+=new BidirectTCPChannel.BidirectTCPTransportHandler. notifyClientClosingDelegate(

87

_clientChannel.removeTransportHandler); } else _clientTHandler=(BidirectTCPTransportHandler) _clientChannel.TransportHandlers[_serverIPAddress.ToString()+ ":"+_serverPort.ToString()];

Slika 10.7: Dodjeljivanje prijenosnog rukovatelja prijenosnom ponoru klijenta

Prilikom instanciranja novog prijenosnog rukovatelja, prijenosni kanal se registrira za događaj zatvaranja prijenosnog rukovatelja kako bi se njegova referenca uklonila iz spremnika procesa kanala. Tablica referenci prijenosnih rukovatelja je sadržana u objektu klase HybridDictionary. Svaki prijenosni ponor registrira se za obavješćivanje događaja ponovnog povezivanje s poslužiteljem, kako bi se novi prijenosni rukovatelj mogao instancirati i dodijeliti odgovarajućim postojećim prijenosnim ponorima. U nastavku je naveden relevantni programski odsječak.

_clientTHandler.notifyClientReconnectEvent+=new BidirectTCPChannel.BidirectTCPTransportHandler.

notifyClientReconnectDelegate(reconnectClientTransportHandler);

Slika 10.8: Registriranje za obavješćivanje događaja ponovnog povezivanja s poslužiteljem

Ako je potrebno stvoriti novog prijenosnog rukovatelja, unutar tog procesa je uključeno spajanje klijenta i poslužitelja na razini pristupnih točki (engl. socket) odnosno TCP razini. U slučaju da je identifikator klijenta clientEndPointId jednak nuli (njegova vrijednost predstavlja jedan od argumenata konstruktora prijenosnog rukovatelja), poslužitelj generira novi identifikator i pošalje ga klijentu koji ga lokalno pohrani. Međutim, ukoliko je identifikator klijenta veći od nule, njegovu vrijednost primi poslužitelj i koristi je u daljnjoj identifikaciji klijenta kako bi ponovno uspostavljanje veze uzrokovano padom veze između klijenta i poslužitelja bilo uspješno završeno i u potpunosti transparentno prema obje strane. Nakon uspješno završenog rukovanja (engl. handshaking), u novo instanciranom prijenosnom rukovatelju pokreću se dvije dretve. Radi se o dretvi primatelja koja obavlja posao čekanja i čitanja podataka iz pristupne točke i raspodjele primljenih poruka na obradu, te dretvi predajnika, koja ima za zadatak slati generirane poruke pohranjene u redu. Slika 10.9 prikazuje dijagram aktivnosti ([3], [20]) vezanih uz uspostavljanje veze klijenta s poslužiteljem na strani klijenta.

88

Instanciraj novi BidirectClientTransportSink

Da li postoji BidirectTCPTransportHandler s ključem

"ipPoslužitelja:pristup"?

Da

Dodijeli postojeći BidirectTCPTransportHandler

Instanciraj novi BidirectTCPTransportHandler

Ne

Spoji se s transportnim kanalom poslužitelja

Da li je poslužitelju poslan clientEndPointId veći od 0?

Ne

Primi novi clientEndPointId od poslužitelja Da

Pokreni dretvu primatelja

Pokreni dretvu predajnika

Registriraj kanal klijenta za obavješćivanje zatvaranja prijenosnog rukovatelja

Registriraj transportni ponor za obavješćivanje rekonekcije prijenosnog rukovatelja

Slika 10.9: Inicijalizacija veze na strani klijenta

10.2.5. Inicijalizacija veze na strani poslužitelja Klasa BidirectTCPListener odgovorna je za osluškivanje zahtjeva za vezom od strane klijenta na razini TCP pristupnih točki te usuglašavanje identifikatora klijenta sa samim klijentom. Instancira se po jedan objekt ove klase za svaki prijenosni kanal. Programski odsječak implementacije prikazan je na slici 10.10.

TcpListener listener=new TcpListener(_localIPAddress, _localPort); _localPort=((IPEndPoint) listener.LocalEndpoint).Port; listener.Start(); while (true) { Socket client=listener.AcceptSocket();

89

IPEndPoint clientEndPoint=(IPEndPoint) client.RemoteEndPoint; int len=client.Receive(buf, 0, 4, SocketFlags.None); int clientEndPointId=buf[0]+(256*buf[1])+(65536*buf[2])+ (16777216*buf[3]); if (clientEndPointId==0) { _endPointIds++; buf[0]=(byte) _endPointIds; buf[1]=(byte) (_endPointIds >> 8); buf[2]=(byte) (_endPointIds >> 16); buf[3]=(byte) (_endPointIds >> 24); client.Send(buf, 0, 4, SocketFlags.None); clientEndPointId=_endPointIds; } BidirectTCPTransportHandler serverTHandler=new BidirectTCPTransportHandler(clientEndPoint.Address, clientEndPoint.Port, _serverTransportSink, client, 0); lock (_serverChannel.TransportHandlers) { _serverChannel.TransportHandlers[clientEndPointId]= serverTHandler; } serverTHandler.ClientEndPointId=clientEndPointId; serverTHandler.notifyServerClosingEvent+=new BidirectTCPChannel.BidirectTCPTransportHandler. notifyServerClosingDelegate( _serverChannel.removeTransportHandler); }

Slika 10.10: Inicijalizacija veze na strani poslužitelja

Budući se sa sigurnošću zna kako se radi o novom klijentu ili ponovnom povezivanju, uvijek se instancira novi prijenosni rukovatelj, jer bi u suprotnom postojeći klijent iskoristio postojećeg prijenosnog rukovatelja. Također, prijenosni kanal se registrira za događaj zatvaranja prijenosnog rukovatelja kako bi se njegova referenca uklonila iz tablice prijenosnih rukovatelja sadržane unutar objekta HybridDictionary prijenosnog kanala poslužitelja. Analogno situaciji klijenta, pokreću se dretva primatelja i dretva predajnika unutar novo instanciranog prijenosnog rukovatelja. Slika 10.11 prikazuje dijagram aktivnosti vezanih uz uspostavljanje veze klijenta s poslužiteljem na strani poslužitelja.

90

Slika 10.11: Inicijalizacija veze na strani poslužitelja

10.2.6. Prijenosni rukovatelj Dvije važne metode koje prijenosni rukovatelj pruža za prosljeđivanje poziva udaljene metode su metoda sendRequestStream() za sinkrone pozive i metoda sendAsyncRequestStream() za asinkrone pozive. Kod sinkronog poziva udaljene metode, pozivajuća dretva se blokira te čeka na signal kojeg postavlja dretva primatelja prilikom prihvata poruke odgovora. Implementacija je navedena na slici 10.12.

internal BidirectTCPMessage sendRequestStream( ITransportHeaders requestHeaders, Stream requestStream) { long requestId=System.Threading.Interlocked.Increment(ref _requestIds); _requestResponse[requestId]=null; AutoResetEvent evt=new AutoResetEvent(false); _requestResponseEvents[requestId]=evt;

91

requestHeaders["__RequestId"]=requestId; MemoryStream transportStream= BidirectTCPChannelHelper.getTransportStream( requestHeaders, requestStream); _senderQueue.Enqueue(transportStream); evt.WaitOne(); BidirectTCPMessage responseMessage= (BidirectTCPMessage) _requestResponse[requestId]; return responseMessage; }

Slika 10.12: Slanje toka podataka sinkronog poziva udaljene metode

S druge strane, kod asinkronog poziva udaljene metode, nema blokiranja pozivajuće dretve već prijenosni rukovatelj pamti referencu na stog ponora kojem treba proslijediti poruku odgovora, što je prikazano na slici 10.13.

internal void sendAsyncRequestStream( ITransportHeaders requestHeaders, Stream requestStream, IClientResponseChannelSinkStack clientSinkStack) { long requestId=System.Threading.Interlocked.Increment(ref _requestIds); requestHeaders["__RequestId"]=requestId; _requestResponse[requestId]=clientSinkStack; MemoryStream transportStream= BidirectTCPChannelHelper.getTransportStream( requestHeaders, requestStream); _senderQueue.Enqueue(transportStream); }

Slika 10.13: Slanje toka podataka asinkronog poziva udaljene metode

Prilikom poziva udaljene metode, bilo sinkrono ili asinkrono, generira se identifikator zahtjeva koji je jedinstven unutar procesa klijenta. Ovaj identifikator se stavlja u prijenosno zaglavlje poruke pod ključ "__RequestId", dok u poruci odgovora prijenosno zaglavlje će sadržavati istu vrijednost identifikatora pod ključem "__ResponseId" kako bi bilo moguće proslijediti odgovor odgovarajućoj dretvi odnosno stogu ponora. Dretva primatelja ima zadaću čitati tok podataka iz pristupne točke i formirati objekt poruke razdvajanjem toka na prijenosno zaglavlje i poruku zahtjeva odnosno odgovora. Vrstu poruke identificira prisustvo ključa "__RequestUri" u prijenosnom zaglavlju, koje definira poruku kao zahtjev, odnosno njegovo izostajanje što implicira da je poruka odgovor. Navedeno je prikazano na slici 10.14.

if (responseHeaders["__RequestUri"]==null) { long responseId= Convert.ToInt64(responseHeaders["__ResponseId"]); if (_requestResponse[responseId]==null) // odgovor na sinkroni // poziv metode { _requestResponse[responseId]=new BidirectTCPMessage( responseHeaders, responseMemoryStream); ((AutoResetEvent) _requestResponseEvents[responseId]).Set(); } else ((IClientChannelSinkStack) _requestResponse[responseId]).AsyncProcessResponse(

92

responseHeaders, responseMemoryStream); } else { processStreamDelegate del=new processStreamDelegate( _serverTransportSink.processStream); del.BeginInvoke(responseMemoryStream, responseHeaders, this, new AsyncCallback(processStreamCallback), del); }

Slika 10.14: Dekodiranje primljenog toka podataka

Ako je vrsta poruke zahtjev, prijenosni rukovatelj pokreće asinkronu obradu zahtjeva prosljeđivanjem poruke prijenosnom ponoru koji poslužuje ciljni udaljeni objekt. U slučaju da se radi o poruci odgovora, prijenosni rukovatelj signalizira dretvu pozivatelja s odgovorom ako je zahtjev bio sinkroni, dok za asinkroni zahtjev poruku jednostavno prosljeđuje stogu ponora na obradu. Dretva predajnika ima jednostavan zadatak dohvata poruke iz reda* pošiljatelja i njenog slanja u pristupnu točku, kao što se vidi na slici 10.15.

try { while (_activeTransportHandler) { transportStream=(MemoryStream) _senderQueue.Dequeue(); lock (_clientSocket) { len=_clientSocket.Send(transportStream.ToArray(), 0, (int) transportStream.Length, SocketFlags.None); } } } catch (Exception ex) { doCleanUp(); _receiveThread.Abort(); }

Slika 10.15: Slanje toka podataka u pristupnu točku

Slika 10.16 prikazuje dijagram aktivnosti vezane uz dretvu primatelja i dretvu predajnika prijenosnog rukovatelja.

* Red ima blokirajuće svojstvo, a ostvaren je unutar klase BlockingQueue čiji je autor William Stacey.

93

Dohvati poruku iz repa pošiljatelja

Pošalji poruku kroz postojeću TCP vezu

Primi poruku iz postojeće TCP veze

Da li je poruka zahtjev?Ne

Da

Asinkrono pokreni obradu zahtjeva

Da li postoji stog ponora u memoriji s ključem "id odgovora"?

Da

Asinkrono obradi odgovor proslijeđujući poruku stogu ponora

Enkapsuliraj odgovor u novi BidirectTCPMessage

Stavi novi BidirectTCPMessage u memoriju s ključem "id odgovora"

Ne

Notificiraj dretvu pozivatelja da nastavi s obradom odgovora

Slika 10.16: Prijenosni rukovatelj

10.3. Demonstracija zaobilaženja sigurnosne stijene

Za demonstraciju zaobilaženja sigurnosne stijene dvosmjernim .NET Remoting komunikacijskim kanalom korišten je ostvareni IRC sustav s jednim poslužiteljem i dva klijenta. Prvi klijent koristi .NET Remoting komunikacijski kanal koji dolazi kao sastavni dio .NET radnog okruženja (TcpChannel), dok drugi klijent koristi dvosmjerni komunikacijski kanal opisan u ovom poglavlju (BidirectTCPChannel). Poslužitelj je podešen da obrađuje zahtjeve pomoću oba komunikacijska kanala i koristi pristup 1234 za posluživanje zahtjeva kanalom TcpChannel i pristup 1235 za posluživanje zahtjeva kanalom BidirectTCPChannel. Sadržaj konfiguracijske datoteke poslužitelja je prikazan na slici 10.17.

94

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="REMOTIRCServer.REMOTIRCServer, REMOTIRCServer" objectUri="REMOTIRCServer" /> </service> <channels> <channel ref="tcp" port="1234"> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> <clientProviders> <formatter ref="binary" /> </clientProviders> </channel> <channel type="BidirectTCPChannel.BidirectTCPServerChannel, BidirectTCPChannel" port="1235" callback="yes"> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> </application> <customErrors mode="Off" /> </system.runtime.remoting> </configuration>

Slika 10.17: Konfiguracijska datoteka poslužitelja

Sadržaj konfiguracijske datoteke prvog klijenta je prikazan na slici 10.18, dok je sadržaj konfiguracijske datoteke drugog klijenta prikazan na slici 10.19. Masnim slovima su naznačene razlike u konfiguracijama.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type="General.IREMOTIRCServer, General" url="tcp://192.168.0.179:1234/REMOTIRCServer" /> </client> <channels> <channel ref="tcp" port="0"> <clientProviders> <formatter ref="binary" /> </clientProviders> <serverProviders> <formatter ref="binary" typeFilterLevel="Full" /> </serverProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> Slika 10.18: Konfiguracijska datoteka klijenta koji koristi Microsoftov .NET Remoting kanal

TcpChannel

95

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type="General.IREMOTIRCServer, General" url="btcp://192.168.0.179:1235/REMOTIRCServer" /> </client> <channels> <channel type="BidirectTCPChannel.BidirectTCPClientChannel, BidirectTCPChannel" callback="yes"> <clientProviders> <formatter ref="binary" /> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> Slika 10.19: Konfiguracijska datoteka klijenta koji koristi dvosmjerni .NET Remoting kanal

BidirectTCPChannel

Između klijenata i poslužitelja je postavljena sigurnosna stijena koja ne propušta nikakav promet prema klijentima iniciran izvana. To znači da klijenti mogu uspostavljati TCP veze prema poslužitelju, dok poslužitelj prema klijentima ne može. Po jedna poruka je poslana s oba klijenta. Klijent koji koristi kanal BidirectTCPChannel uredno je primio obje poruke, dok klijent koji koristi kanal TcpChannel nije primio niti jednu poruku. Kako taj klijent očekuje uspostavljanje nove TCP veze u svrhu povratnog poziva poslužitelja, on uspijeva poslati poruku poslužitelju ali ne i primiti je jer to ne dozvoljava sigurnosna stijena. Međutim, klijent koji koristi kanal BidirectTCPChannel iskorištava istu TCP vezu i za povratni poziv pa uspjeva primiti obje poruke budući se komunikacija odvija tranparentno prema sigurnosnoj stijeni. Rezultat ovog testa je prikazan na slikama 10.20 i 10.21.

96

Slika 10.20: IRC klijent koji koristi Microsoftov .NET Remoting kanal TcpChannel

Slika 10.21: IRC klijent koji koristi dvosmjerni .NET Remoting kanal BidirectTCPChannel

97

11. Zaključak

Raspodijeljeno programiranje je opisano s nekoliko fizički zasebnih komponenti koje zajedno funkcioniraju kao jedinstveni sustav. Fizički zasebne komponente ovdje mogu označavati više procesora, ili što je učestalije, više računala na mreži. Raspodijeljeno programiranje se može primijeniti na široki spektar problema, od vremenske prognoze do kupovine knjiga. U svojoj srži, raspodijeljeno programiranje sadrži sljedeću pretpostavku: ako vrijedi da jedno računalo može završiti neki zadatak za pet sekundi, tada bi pet računala radeći paralelno trebala završiti isti zadatak u jednoj sekundi. Naravno, u praksi nikad nije tako jednostavno. U ovom radu su opisane neke od najvažnijih tehnika raspodijeljenog programiranja. Posebno je posvećena pažnja arhitekturi, protokolima i sigurnosti svake tehnike. Također je prikazana usporedba tehnika s obzirom na učinkovitost, stabilnost, prenosivost, lakoću programiranja i sigurnost, te je izvučen zaključak da su od razmatranih tehnika Java RMI i XML-RPC najjednostavnije, dok je DCOM najsloženiji za primjenu. Prilikom ispitivanja djelotvornosti, ONC RPC se pokazao najučinkovitijim, dok je XML-RPC pokazao najslabija svojstva. U drugom dijelu rada opisan je sustav zaštićen sigurnosnom stijenom, te su istraženi načini omogućavanja povratnog poziva s vanjskog poslužitelja. Praktičnim dijelom se pokazalo rješenje problema dvosmjerne komunikacije u obliku dvosmjernog .NET Remoting komunikacijskog kanala. Ovo rješenje se temelji na iskorištavanju otvorene TCP/IP veze od strane klijenta za komunikaciju u oba smjera. Na ovaj način, poslužitelj, koji se nalazi s vanjske strane zaštićenog sustava, ima mogućnost povratnog poziva, odnosno poziva udaljene metode klijenta jer koristi upravno onu vezu koju je taj klijent i inicirao. Ovakva komunikacija prolazi kroz sigurnosnu stijenu jer zadovoljava sve sigurnosne politike, za razliku od klasičnog načina povratnog poziva gdje poslužitelj pokušava otvoriti novu vezu prema klijentu preko koje bi slao zahtjeve i primao odgovore. Međutim, ovaj način završava neuspješno iz dva razloga. Prvi predstavlja sigurnosnu politiku koja ne dozvoljava iniciranje komunikacijskih kanala od strane poslužitelja s vanjske strane sigurnosne stijene, dok se drugi odnosi na korištenje mehanizma NAT unutar lokalne mreže, koji prema vanjskom svijetu skriva privatne IP adrese klijenata. Kad se govori o vanjskoj strani sigurnosne stijene, odnosno vanjskom svijetu, tada se uglavnom misli na globalnu mrežu Internet, međutim odnosi se i na segmentiranu LAN/WAN mrežu. Glavni nedostatak ostvarenog dvosmjernog kanala leži u činjenici da sigurnosna stijena mora propustiti iniciranu vezu klijenta prema van kroz određeni pristup ili koristiti pristupnik na aplikacijskoj razini koji je konfiguriran za propuštanje .NET Remoting protokola. Međutim, sigurnosne politike postaju sve strože i vrlo je čest slučaj gdje korisnici LAN mreže imaju pristup vanjskom svijetu samo preko HTTP pristupnika. Kako bi se i ovo ograničenje uspješno zaobišlo, potrebno je ostvareni dvosmjerni kanal podići na aplikacijsku razinu te protokol omotati unutar HTTP omotnice. Također je potrebno koristiti stalnu vezu uvedenu u verziji 1.1 protokola HTTP (RFC 2068) [48].

98

Literatura

[1] Jesse Liberty, Programming C#, Publisher: O'Reilly, Second Edition, 2002 [2] Eric Butow and Tommy Ryan, C#: Your visual blueprint for building .NET applications, Hungry Minds, Inc., New York, 2002 [3] Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley, First Edition 1998 [4] Andrew S. Tanenbaum, Distributed Operating Systems, Prentice Hall, 1995 [5] David Reilly, Michael Reilly, Java™ Network Programming and Distributed Computing, Addison Wesley, 2002 [6] Gerald Brose, Andreas Vogel, Keith Duddy, Java Programming with Cobra, Advanced Techniques for Building Distributed Applications, Wiley Computer Publishing, Third Edition 2001 [7] Scott McLean, James Naftel, Kim Williams, Microsoft .NET Remoting, Microsoft Press, 2003 [8] William Grosso, Java RMI, O'Reilly, First Edition, 2001 [9] Randy Abernethy, COM/DCOM Unleashed, Macmillan Computer Publishing, Publication 1999 [10] Klaus Bergner, Andreas Rausch, Marc Sihling, Using UML for Modeling a Distributed Java Application, Technische universitat munchen, 1997 [11] Sten Sundblad and Per Sundblad, Designing for Scalability with Microsoft Windows DNA, Microsoft Press, 2000 [12] Cameron Hughes, Tracey Hughes, Parallel and Distributed Programming Using C++, Addison Wesley, Pub 2003 [13] Jean Bacon, Tim Harris, Operating Systems: Concurrent and Distributed Software Design, Addison Wesley, 2003 [14] Jim Miller, Susann Ragsdale, The Common Language Infrastructure Annotated Standard, Addison Wesley, 2003 [15] Ingo Rammer, Advanced .NET Remoting (C# Edition), Apress, 2002 [16] Tom Barnaby, Distributed .NET Programming in C#, Apress, 2002 [17] Judith M. Myerson, The Complete Book of Middleware, Auerbach Publications, 2002 [18] Tom Archer, Andrew Whitechapel, Inside C#, Microsoft Press, 2002 [19] Matthew MacDonald, Microsoft® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting, Microsoft Press, 2003 [20] Sinan Si Alhir, Learning UML, O'Reilly, 2003 [21] Richard Blum, C# Network Programming, Sybex, 2003

99

Web izvori su provjereni 31.05.2005.

[22] COM versus CORBA A Decision Framework, http://www.scit.wlv.ac.uk/~cm1924/cp3025/distrib/reading/corba/corba3/corba6.html [23] Remote Procedure Call, http://rzaix12.rrz.uni-hamburg.de/doc_link/en_US/a_doc_lib/aixprggd/progcomc/toc.htm [24] DCOM and CORBA Side by Side, Step By Step, and Layer by Layer, http://research.microsoft.com/~ymwang/papers/HTML/DCOMnCORBA/S.html [25] DCOM,CORBA,Java-RMI - A Step by Step Comparison by Gopalan Suresh Raj, http://my.execpc.com/~gopalan/misc/compare.html [26] Distributed Computing An Introduction, http://www.extremetech.com/article2/0%2C1558%2C11769%2C00.asp [27] Programming with ONC RPC-a, http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-Q0R5B-TET1_html/TITLE.html [28] RFC 1831 – RPC: Remote Procedure Call Protocol Specification Version 2, http://www.ietf.org/rfc/rfc1831.txt [29] Common Object Request Broker Architecture: Core Specification, Version 3.0.3, March 2004 [30] Remote Procedure Call, http://www.sei.cmu.edu/str/descriptions/rpc.html [31] Anna Liu, Evaluating Middleware Technologies, http://www.acs.org.au/nsw/chapters/westsyd/meetings/200206pres.zip [32] Chris Mayers, Using Remote Procedure Call Standards, http://www.ansa.co.uk/ANSATech/96/Briefing/16530002.pdf#search='Using%20Remote%20Procedure%20Call%20Standards [33] Middleware – COM/DCOM, Software Architectures, 2001, http://sunset.usc.edu/classes/cs578_2001/April19.PDF#search='Middleware%20%E2%80%93%20COM%2FDCOM

[34] Randy Charles Morin, DCOM Bi-Directional Communication Derby Callbacks vs Connection Points, http://www.kbcafe.com/articles/Bidirectional.DCOM.pdf#search='Randy%20Charles%20MorinBiDirectional%20Communication%20Derby%20Callbacks%20vs%20Connection%20Points

[35] Abhishek Patil, Rajesh Korde, Kapil Sabharwal, Comparison of Middleware Technologies - CORBA, RMI & COM/DCOM, http://www.cse.msu.edu/~patilabh/research/Final_Report.pdf#search='Abhishek%20Patil%2C%20Rajesh%20Korde%2C%20Kapil%20SabharwalComparison%20of%20Middleware%20Technologies%20%20CORBA%2C%20RMI%20%26%20COM%2FDCOM

[36] Farnam Jahanian, EECS 498 – Lecture Notes #1c Overview of Distributed Computing Paradigms, http://www.eecs.umich.edu/~farnam/498/handout1c.pdf#search='Farnam%20JahanianEECS%20498%20%E2%80%93%20Lecture%20Notes%201c%20Overview%20of%20Distributed%20Computing%20Paradigms

100

[37] The JacORB Team, JacORB 2.2 Programming Guide, 2004, http://www.jacorb.org/releases/2.2/ProgrammingGuide.pdf.gz

[38] Daniel J. Jensen, MIGRATION OF LEGACY DCE SYSTEMS, Masters Thesis, 2002, http://www.kaweah.com/Research/oodce2corba/Thesis.pdf#search='Daniel%20J.%20JensenMIGRATION%20OF%20LEGACY%20DCE%20SYSTEMS

[39] Robert I. Griffin, Firewall Traversal for CORBA Applications Using an Implementation of Bidirectional IIOP in MICO, 2002, http://gltrs.grc.nasa.gov/reports/2002/CR-2002-211979.pdf

[40] Meenakshi Sundar Sethuraman, Framework For Accessing CORBA Objects With Internet As The Backbone, Masters Thesis, 2001, http://etd.fcla.edu/etd/uf/2001/anp1296/master.pdf

[41] Borland Software Corporation, Enterprise Server 6.5, VBGateKeeper Guide, http://info.borland.com/techpubs/bes/v65/pdfs/allbooks.zip

[42] Esmond Pitt and Neil Belford, The RMI Proxy, 2002, http://www.rmiproxy.com/doc/WhitePaper.pdf#search='Esmond%20Pitt%20and%20Neil%20Belford

[43] Deborah J. Bodeau, Charles M. Schmidt, Vipin Swarup, F. Javier Thayer, Distributed Object Computing (DOC), Security: Paradigms and Strategies, 1998, http://www.mitre.org/work/tech_papers/tech_papers_99/bodeau_docsec/bodeau_docsec.pdf#search='Deborah%20J.%20BodeauDistributed%20Object%20Computing%20%28DOC%29 [44] Java Remote Method Invocation Specification, Sun Microsystems, http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html [45] Guy Eddon and Henry Eddon, Understanding the DCOM Wire Protocol by Analyzing Network Data Packets, March 1998, http://www.microsoft.com/msj/0398/dcom.aspx

[46] Message Passing Interface (MPI), http://www.mhpcc.edu/training/workshop/mpi/MAIN.html [47] Java Authentication and Authorization Service (JAAS), Reference Guide for the Java 2 SDK, Standard Edition, v 1.4, http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html

[48] RFC 2068 – Hypertext Transfer Protocol -- HTTP/1.1, http://www.ietf.org/rfc/rfc2068.txt

101

Popis kratica

ACE API ASP.NET ATL AWT BOA CAO CDR CLSID COM CORBA DACL DCE DCOM DES DII DLL DSI FTP GIOP GUID HPC HTTP ID IDL IETF IIOP IIS IOR IP IPID

Access Control Element Application Programming Interface Active Server Pages .NET Active Template Library Abstract Window Toolkit Basic Object Adapter Client-Activated Object Common Data Representation Class ID Component Object Model Common Object Request Broker Architecture Discretionary Access Control List Distributed Computing Environment Distributed COM Data Encryption Standard Dynamic Invocation Interface Dynamic Link Library Dynamic Skeleton Interface File Transfer Protocol General Inter-ORB Protocol Globally Unique Identifier High Performance Computing Hypertext Transfer Protocol Identifier Interface Definition Language Internet Engeenering Task Force Internet Inter-ORB Protocol Internet Information Services Interoperable Object Reference Internet Protocol Interface Pointer Identifier

102

IPSec IRC ISO J2SE CORBA JAAS JRMP JVM LAN LPC MIDL MPI MSMQ NAT NDR NetBEUI NetBIOS NFS NNTP NTLMSSP OMG ONC RPC OOP ORB ORPC OXID PAM PDU POA RFC RMI RPC SACL SAO SCM

IP Security Protocol Internet Relay Chat International Organisation for Standardization Java 2 Platform, Standard Edition CORBA Java Authentication and Authorization Service Java Remote Method Protocol Java Virtual Machine Local Area Network Local Procedure Call Microsoft Interface Definition Language Message Passing Interface Microsoft Message Queuing Network Address Translation Network Data Representation NetBIOS Extended User Interface Network Basic Input Output System Network File System Network News Transfer Protocol NT Lan Manager Security Service Provider Object Management Group Open Network Computing RPC Object-Oriented Programming Object Request Broker Object Remote Procedure Call Object eXporter Identifier Pluggable Authentication Module Protocol Data Unit Portable Object Adapter Request For Comments Remote Method Invocation Remote Procedure Call System Access Control List Server-Activated Object Service Control Manager

103

SESAME

SID SMP SMTP SOAP SSL SSPI TCP TLS TTL UDDI

UDP URL VMTP W3C WAN WSDL XDR XML

Secure European System for Applications in a Multi-vendor Environment Security ID Symmetric MultiProcessing Simple Mail Transfer Protocol Simple Object Access Protocol Secure Socket Layer Security Support Provider Interface Transmission Control Protocol Transport Layer Security Time-To-Live Universal Description Discovery and Integration User Datagram Protocol Uniform Resource Locator Versatile Message Transaction Protocol World Wide Web Consortium Wide Area Network Web Services Definition Language eXternal Data Representation eXtensible Markup Language

104

Sažetak

U prvom dijelu ovog rada opisane su neke od najznačajnijih tehnika raspodijeljenog programiranja. Najviše se prostora posvetilo tehnikama ONC RPC, CORBA, Java RMI, DCOM i .NET Remoting. Od ostalih tehnika spomenute su Web usluge, XML-RPC i MPI. Tehnike su međusobno uspoređene s obzirom na učinkovitost, stabilnost, prenosivost, lakoću programiranja i sigurnost. U drugom dijelu rada opisan je sustav zaštićen sigurnosnom stijenom, te su istraženi načini omogućavanja povratnog poziva s vanjskog poslužitelja. Praktičnim dijelom se pokazalo rješenje problema dvosmjerne komunikacije u obliku dvosmjernog .NET Remoting komunikacijskog kanala, koji koristi istu TCP/IP vezu stvorenu od strane klijenta za komunikaciju u oba smjera. Ključne riječi: raspodijeljeno programiranje, ONC RPC, CORBA, Java RMI,

DCOM, .NET Remoting, Web usluga, XML-RPC, MPI, sigurnosna stijena, filtriranje paketa, pristupnik.

105

Summary

Distributed programming techniques in a firewalled system The first part of this thesis describes some of the most important techniques of distributed programming. The largest amount of time and space was devoted to ONC RPC, CORBA, Java RMI, DCOM and .NET Remoting techniques. Other techniques that were briefly mentioned are Web Services, XML-RPC and MPI. The techniques were mutually compared with regards to efficiency, stability, portability, ease of programming and security. The second part of this thesis elaborates the system protected by a firewall, and presents possible solutions to the problem of callbacks from the outside server. With the practical part of the thesis, a solution to the problem of a two-way communication was shown in the form of a bidirectional .NET Remoting communication channel that uses the same TCP/IP connection created by a client for the communication in both directions. Key words: distributed programming, ONC RPC, CORBA, Java RMI, DCOM, .NET

Remoting, Web service, XML-RPC, MPI, firewall, packet filtering, gateway.

106

Životopis

Rođen sam 14.08.1979. godine u Zagrebu, gdje sam završio osnovnu školu i prve dvije godine Pete gimnazije. Zadnje dvije godine srednje škole završio sam na Hendon College-u u Londonu 1997. godine. Iste godine vraćam se u Zagreb i upisujem studij na Fakultetu elektrotehnike i računarstva, smjer računarstvo, gdje sam u srpnju 2002. godine diplomirao s izvrsnim uspjehom. Tema diplomskog rada bila je "Informacijski sustav za potporu rada Društva Multiple Skleroze Hrvatske". Nakon završenog studija, u listopadu 2002. zapošljavam se u Hrvatskoj elektroprivredi te u studenom 2002. godine upisujem poslijediplomski studij na Fakultetu elektrotehnike i računarstva u Zagrebu.

tehnike raspodijeljenog programiranja u sustavu sa...

Documents