[es] - Distribuirane aplikacije

eon

Član broj: 10450
Poruke: 53
*.as54.bi.bih.net.ba.

Profil

^{19.06.2004. u 21:24 - pre 253 meseci}

Procitao sam neke tutoriale u MSDN-u, pa sam pokusao raditi nesto slozeniju distribuiranu aplikaciju namijenjenu bibliotekama. Trebala bi se sastojati iz sljedecih dijelova:

1. client - win/web forms
2. web service
3. business logic
4. sloj za pristup bazi
5. baza podataka

Win klijent bi trebalo da radi glavne stvari oko biblioteke, unos autora, knjiga, clanova, izdavanje knjiga itd.
(Eventualno, kasnije bi se i za te poslove napravio web klijent.)

Osnovni web klijent bi imao mogucnost pregleda kataloga knjiga, po grupama, autorima, po čitanosti, kontrola da li je neka knjiga zauzeta (izdata) i sl. To bi omogucavalo članovima i javnosti uvid u fond biblioteke.

Oba klijenta bi komunicirali iskljucivo sa web servisom.
Oba klijenta, windows forms aplikacija, ili asp.net web aplikacija mogu se nalaziti na racunaru razlicitom od web servisa. Baza podataka takodje mogla bi imati svoj racunar.

Web service, business logic i sloj za pristup bazi podataka bi morali biti na jednom racunaru.

Sad, nekoliko stvari me muci.
Prvo, ima li smisla razdvajati web service, business logic i data access sloj zasebno, ako ih ne pravim tako da se mogu izvrsavati na razlicitim racunarima?

Drugo, u primjerima enterprise distribuiranih aplikacija, business logic je razdvojen na business facade i business rules. Jel' to nesto sto je neophodno ili se to sve moze staviti u jedan sloj? Ako odredjena akcija ne zahtijeva nikakvu posebnu kontrolu, recimo unos podataka o autorima, moze li web service ili business facade preskociti ovaj sloj i pozvati data access sloj direktno?

Treće, da li je uobicajeno da se pravi samo jedan web service, a ne vise koji bi u ovom slucaju opsluzivao sve zahtjeve, ili se moze praviti i vise sa razlicitim namjenama?

Četvrto, gdje da stavim security sloj? Kontrola prava za radnike u biblioteci, kontrola za administratora aplikacije, eventualno kontrola pristupa članova putem web klijenta (ako bih im dopustio, npr. rezervisanje i slicne stvari) zahtijevaju da ih autoriziram te da negdje, neki od ovih slojeva odlucuje da li im ispuniti zahtjev ili ne. Da li je web service pogodan za to, ili da to prepustim nekom sloju ispod? Kako izvesti autorizaciju, da li pri svakom pozivu web servisa da saljem username/password (sto mi izgleda najjednostavnije za sada)?

Ima ovdje gomila pitanja, valjda cemo uspjeti naci nekakva rjesenja. A pitacu ja jos.

Odgovor na temu

havramm
Miroslav Havram
Software Developer / Engineer
Beograd

Član broj: 4603
Poruke: 255
212.62.55.*

Profil

Re: Distribuirane aplikacije

^{19.06.2004. u 22:31 - pre 253 meseci}

1. Naravno da ima smisla. Uradi to zbog sebe i ljudi koji ce eventualno to raditi posle tebe. Bez obzira da li ce ti slojevi biti fizicki razdvojeni (na razlicitim racunarima), veoma je dobra praksa da se logicki radvoje. Znaci, napravi DAL i Bussines Process komponente i kao facade na to Web servis, DAL -> BP -> WS.

2. Tu sada postoje dva pristupa: striktni, gde svaki sloj moze da komunicira samo sa slojem direktno ispod njega (ne moze sa slojem iznad i ne moze sa nizim slojevima od prvog nizeg) i drugi, "relaxed", u kome sloj moze da komunicira sa svim nizim slojevima. Ovaj drugi se preporucuje za slucajeve da se ne moraju menjati neki medjuslojevi ako se promene oni nizi, kao i izbegavanje da sloj ne radi nista vec samo prosledjuje poruke sloju ispod. U svakom slucaju, izricito se ne preporucuje komuniciranje sa slojem iznad!

3. Kako je tebi lakse i kako mislis da ce biti lakse za odrzavanje.

4. Pa oprilike tu negde u BP sloju, pre DAL-a, to mi je uvek najteze da odlucim

. Sto se tice sigurnosti poziva Web Servisa, potrazi na Code Magazine broj jul/aug 2003 gde su fino prikazani neki od pristupa.

[Ovu poruku je menjao havramm dana 20.06.2004. u 15:48 GMT]

If it's a girl then they're gonna call it Sigourney, after an actress. If it's a boy, then they're gonna call it Rodney, after Dave!

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Distribuirane aplikacije

^{20.06.2004. u 11:01 - pre 253 meseci}

1. Minimum razdvajanja koji bi morao da imaš je na nivou klasa (da dva layer-a ne obuhvataju istu klasu). Najčešće praktikovan metod je da svaki layer dobije svoj projekat (class library), pošto time dobijaš lepu celinu koju možeš koristiti i u drugim projektima. Npr. u fazi 2 biblioteka kupi SMS gateway i ti sad proširuješ svoju aplikaciju tako da šalje SMS opomene ljudima koji kasne sa vraćanjem knjiga. Tu više nećeš pozivati web service, nego ćeš praviti windows service koji će se nakačiti na business layer, a ako je BL napravljen kao zaseban assembly, biće ti mnogo lakše. Može da se uradi i da svaki layer bude zaseban application domain (EXE), to bi ti olakšalo remoting (mogao bi layere da podeliš po mašinama) ali bi usporilo celu priču (pozivi metoda su spori).

2. Nije neophodno, iskreno, sem u primerima, još u praksi nisam sreo ovo razdvajanje. Ima smisla u baš baš velikim sistemima, u kojima se business rules (BR) često menjaju, a sem sistema za rezervaciju avio karata još nisam video sistem koji dinamički menja set BR-ova. U svakom slučaju za biblioteku ti ne treba, ako i postoje neke varijacije u BR-ovima njih uvek možeš da pokriješ sa if-then-else ili case.

3. U praksi se najčešće koristi jedan web servis u jednoj nosećoj web aplikaciji. Zbog lakšeg korišćenja, zbog lakše administracije, zbog security-a. SOAP pozivi metoda su najsporiji od svih mogućih načina pozivanja, tako da obrati pažnju na to šta i kako primaš i vraćaš (izbegavaj redundantne i nekorisne informacije).
E sad, da podeliš jedan web servis na više web servisa, moguće je, ali se to obično radi kad postoji baš čista granica između business celina pa se teret raspoređuje na dve ili više mašina, ali onda opet moraš da "sliješ" pozive u sledeći layer, itd. Ovo je opet priča za mnogo veće sisteme i tu postoje i mnogo elegantnija rešenja kako softverska (paketna obrada, itd) tako i hardverska (load-balancing, itd)

4. Prosto i jednostavno, u najrigoroznijem scenariju security check stavljaš na svako javno mesto i svako interno mesto koje je dostupno bilo kome sem tvojoj aplikaciji. U ovom tvom slučaju definitivno na web service, web forms i win forms. Ako npr. radiš remoting pozive između layer-a onda je poželjno i tu staviti proveru. Naravno, dobra security analiza uzima mnoge stvari u obzir, sigurnost okruženja, mogućnost nastanka i veličina štete, siguronosne uloge, damage control, itd. Ne pravi se isti security za biblioteku i za banku, narafski.
Lep metod zaštite za ovakve scenarije je tokenizacija. Pri prijavljivanju na sistem, proveriš korisnikov username/password i izdaš mu security token (serializable objekat koji nosi sve security informacije i digitalni potpis), taj token može da se šeta svuda i uvek može da se proveri njegova validnost (proverom potpisa) i siguronosni nivo korisnika.

Problem sa svim ovim pitanjima koja si postavio je da si izašao van granica "programerske" logike, projektovanje enterprise sistema uključuje i mnoge druge tehničke stvari (raspored i kvalitet hardvera, linkovi, geofizički položaj udaljenih stanica, itd) i ne-tehničke stvari (najviše security, ali su tu i procena rizika, ljudski faktor, u krajnjoj liniji čak i da li će jak zemljotres da "obori" kritični deo sistema i lančano obori ceo entrprise :)). Ne postoji magični štapić koji će da stvori gotovo enterprise rešenje, svaki podsistem ima neke svoje mane i prednosti, na projektantima je da shodno prioritetima naručioca uklopi postojeća rešenja u veliki sistem.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

eon

Član broj: 10450
Poruke: 53
*.as54.bi.bih.net.ba.

Profil

Re: Distribuirane aplikacije

^{20.06.2004. u 14:54 - pre 253 meseci}

Hvala vam obojici, ovi odgovori su tacno ono sto sam trazio, mada pocinje da mi se vrti u glavi od ovog enterprise-a.

Jos uvijek imam nejasnocu, vezanu za smjestaj security kontrole.
Ne mislim na prijavu, nju svakako mora obaviti Win/Web klijent i proslijediti je web servicu, koji je autorizira.
Kada se korisnik vec prijavi (recimo da on spada u članove, radnike ili administratore) web servisu (dopao mi se onaj metod preko log-in i sesije u Code magazinu), gdje je mjesto na kome se odlucuje ima li taj korisnik pravo da obavi odredjenu akciju?

Prva mogucnost koja mi pada na pamet je da to sve smjestim u web service. Klijent se prijavi web servisu. Ovaj pozove neki od donjih slojeva i zatrazi iz baze spisak korisnika. Provjeri postoji li korisnik, odgovara li lozinka, te ako odgovara, ocitava njegova prava iz baze.
Posto web service cuva stanje sesije, svaki klijentov zahtjev za odredjenim resursom business sloja ce provjeriti web service, tj. pravila pristupa nalazice se u web servisu. Ako je korisnik administrator, web service ce mu, na zahtjev, pozvati i isporuciti svaki metod donjeg sloja, ako nije onda samo one koje mu dopusta, selektivno.
Problem sa ovim je sto se onda ono sto zapravo logicki spada u business process (prava pristupa) pomjerilo u web service. Ako se desi da se kasnije neki drugi projekat treba povezati sa business process slojem (recimo taj SMS servis ili nesto drugo), on ce imati apsolutni pristup svemu jer business proces isporucuje sve svoje resurse bez kontrole. Ako hocemo uvesti sigurnosna pravila, moracemo ih duplicirati i u tom novom projektu, jer od onih u web servisu nemamo koristi, posto se on ionako zaobilazi.

Druga opcija je da to sve stavim u business layer. U tom slucaju web service ce autorizirati klijenta, provjeriti ispravnost autentikacije pozivom donjem sloju, i cuvace sesiju, ali ce pri svakom pozivu donjeg sloja radi obavljanja neke operacije isporucivati mu username/password. Donji sloj ce, kada se pozove neka metoda, recimo UpdateAuthors, provjeriti korisnika u bazi, provjeriti njegove privilegije i ako ima pravo, obaviti akciju, u suprotnom baciti izuzetak. Problem sa ovim pristupom je sto svaki poziv donjeg sloja zahtijeva da on provjeri bazu s korisnicima i njihove privilegije, sto znacajno usporava proces.

Treca opcija, koja mi se vrti u glavi je da web service prihvati username/pass od klijenta, posalje ih business sloju, ovaj ih prihvati, provjeri i vrati web servisu podatke o autorizaciji, te neku oznaku privilegije. Ako je autentikacija uspjela, web servis ce sacuvati u sesiji (ako je to moguce) oznaku privilegije i sa sljedecim pozivima business sloju slati i nju. Business sloj ce samo ocitati poslanu oznaku i na osnovu nje odluciti da li izvrsiti odredjenu akciju ili isporuciti resurs. Ovo i dalje ostavlja odlucivanje o pravima business sloju, ali ne zahtijeva da ovaj za svaki poziv trazi korisnike u bazi i provjerava njihove privilegije.
Medjutim, ovo mi djeluje nekako suplje, jer se ocekuje "dobra saradnja" web servisa i business sloja, tj. ne izoluje totalno logiku u business sloj, pa se ocekuje da web service bude "iskren" i posalje pravu oznaku privilegije. To i nije problem dok su oni napravljeni da rade iskljicivo zajedno, ali bi bio problem ako bi se business sloju moglo pristupiti udaljeno, tj. neko bi mogao napisati svoj web servis koji ce pozivati business sloj sa udaljenosti i slati mu lazne oznake privilegije.

Ufff...napricah se ja. Pocetnik sam u ovome pa se izvinjavam ako ne mozete razumjeti sta pitam zbog neispravne terminologije i nacina objasnjavanja.
Ovo za sad radim u "edukativne svrhe", ako mi bude islo, trazicu od profesora da mi odobri diplomski na ovu temu, zato i gnjavim ovoliko sa teoretskim dijelom. Kasnije mozda pokusam to utrpati nekoj biblioteci. Mada, kad skontam koliko su ovdje biblioteke posjecene i profitabilne, sumnjam...

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Distribuirane aplikacije

^{20.06.2004. u 16:24 - pre 253 meseci}

Citat:

eon: Jos uvijek imam nejasnocu, vezanu za smjestaj security kontrole.
Ne mislim na prijavu, nju svakako mora obaviti Win/Web klijent i proslijediti je web servicu, koji je autorizira.
Kada se korisnik vec prijavi (recimo da on spada u članove, radnike ili administratore) web servisu (dopao mi se onaj metod preko log-in i sesije u Code magazinu), gdje je mjesto na kome se odlucuje ima li taj korisnik pravo da obavi odredjenu akciju?

Kao što rekoh, u winforms aplikaciji tj. na web sajtu. Duboko je ukorenjena greška da je security deo nekog fisknog layer-a. Nije. Autentikacija korisnika (provera identiteta) se obavlja na jednom mestu, najčešće u BL, ali sama provera autorizacije se obavlja GDE GOD je to potrebno. Naravno da nećeš dozvoliti non-admin korisniku da uđe u admin formu, da unese podatke za novog korisnika i onda tek da ga otkačiš kad BL odbije da obavi akciju

nego ćeš da prilagodiš izgled UI prema siguronosnom profilu korisnika, dakle obavljaš proveru. Razmišljaj o security layer-u kao o vertikalnom layeru koji dodiruje sve ostale.

Citat:

eon: Ako se desi da se kasnije neki drugi projekat treba povezati sa business process slojem (recimo taj SMS servis ili nesto drugo), on ce imati apsolutni pristup svemu jer business proces isporucuje sve svoje resurse bez kontrole.

Što u tvom slučaju i nije problem, zar ne. Ionako ćeš tom servisu morati da dodeliš najviše prioritete pošto će morati da skenira sve ostale članove biblioteke u potrazi za prekršajem. Ali ako baš hoćeš da uvučeš security u BL, onda po gornjem reply-u možeš isto da odradiš, servis će da se autentikuje koristeći predefinisani user/pass direktno u BLu i onda je podložan daljim proverama.

Citat:

eon: Donji sloj ce, kada se pozove neka metoda, recimo UpdateAuthors, provjeriti korisnika u bazi, provjeriti njegove privilegije i ako ima pravo, obaviti akciju, u suprotnom baciti izuzetak. Problem sa ovim pristupom je sto svaki poziv donjeg sloja zahtijeva da on provjeri bazu s korisnicima i njihove privilegije, sto znacajno usporava proces.

Što rešavaš tokenizacijom koju sam pomenuo u prošlom postu, upit u bazu se obavlja samo jednom pri autentikaciji, klijent dobija token objekat i njega možeš da šetaš kroz layere i nad njim može da se proveri autorizacija u bilo kom trenutku, bez da se konsultuje baza.

Citat:

eon: To i nije problem dok su oni napravljeni da rade iskljicivo zajedno, ali bi bio problem ako bi se business sloju moglo pristupiti udaljeno, tj. neko bi mogao napisati svoj web servis koji ce pozivati business sloj sa udaljenosti i slati mu lazne oznake privilegije.

Ok, u hi-security paranoičnom scenariju možeš da proglasiš sam web servis za security entity i zahtevati od njega da se autentikuje u BLu i da uz svaki zahtev BLu prosledi i svoju i korisnikovu autorizaciju

Sky is the limit

Inače, jedina realna odbrana od fakeovanja identiteta ti je kriptografija. Sve ostalo može da se buši na nekom nivou.

Odgovor na temu

eon

Član broj: 10450
Poruke: 53
*.as54.bi.bih.net.ba.

Profil

Re: Distribuirane aplikacije

^{20.06.2004. u 17:55 - pre 253 meseci}

Naravno da nećeš dozvoliti non-admin korisniku da uđe u admin formu, da unese podatke za novog korisnika i onda tek da ga otkačiš kad BL odbije da obavi akciju nego ćeš da prilagodiš izgled UI prema siguronosnom profilu korisnika, dakle obavljaš proveru.

To svakako. Mislim da je odgovarajuci nacin da se UI sloj obavijesti o pravima korisnika kad se logira, pa da se moze prilagoditi tome i ne prikazivati opcije na koje user nema pravo. Medjutim, ovo je samo obavjestenje, da poslije ne bi bilo neugodnih iznenadjenja koja spominjes, ali ne i donosenje odluke o pravima. UI ne moze zaista donositi odluke o svojim privilegijama. U ovom slucaju, cak i kad bi klijent odbio da sakrije prikaz opcija na koje nema pravo (zato sto je crackovan ili posebno napravljen da ignorise obavjestenje o pravima), ne bi ih mogao izvrsiti jer bi BL odbio (taman kad popuni i klikne save

). Dakle, prava odluka o privilegijama se mora obavljati na strani servera.

Ok, ostalo mi je jasno, osim ...
Kako se pravi to cudo od security tokena i kako funkcionise? Ne mislim na code, nego uopste na princip. (valjda nisam previse dosadan

)

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Distribuirane aplikacije

^{21.06.2004. u 00:54 - pre 253 meseci}

Citat:

U ovom slucaju, cak i kad bi klijent odbio da sakrije prikaz opcija na koje nema pravo (zato sto je crackovan ili posebno napravljen da ignorise obavjestenje o pravima), ne bi ih mogao izvrsiti jer bi BL odbio (taman kad popuni i klikne save ). Dakle, prava odluka o privilegijama se mora obavljati na strani servera.

Negde se nismo dobro razumeli. Razlikuj proces autentikacije (provere identiteta, npr. kombinacije user/pass) i proces autorizacije (provera da li korisnik ima pravo na neku akciju). U pomenutom slučaju i UI layer obavlja autorizaciju (proveravajući da li ili ne da korisnika pusti na formu) i BL obavlja identičnu autorizaciju.
Npr, token o kome pričamo može da ima metod bool isInRole(string), pa će i UI i BL autorizaciju obavljati sa if userToken.isInRole("Admin") .... Dakle, security se prožima kroz oba layera. Ti možeš u UI da po samom logovanju isproveravaš sve autorizacije i zapamtiš rezultate ali je to samo keširanje, autorizacija je obavljena pa obavljena.
Autentikacija sa druge strane predstavlja proces kojem je pravo mesto u BLu.

Citat:

Kako se pravi to cudo od security tokena i kako funkcionise?

Evo jedan primer koji bi ovde radio ok (pišem iz glave, pa verovatno mašim sintaksu):

Code:

[Serializable]
public struct TokenData
{
    public int UserID;
    public int Level;
    public datetime Expires;
}

[Serializable]
public class SecurityToken
{   public TokenData User;
   public string signature;
   private string publickey = "<javni kljuc>";
}

UserID je ID, Level je sigurnosni nivo (recimo admin = 0, pa što veći broj to manje prava), Expires označava kad token ističe, signature je asimetrično kriptovani hash (potpis) svih polja iz TokenData. Privatni ključ naravno čuvaš na jednom mestu na serveru (nikako u nekom DLLu koji će biti deo UI dela aplikacije), a public ključ je privatni deo tokena (da ne bi bio serializovan bez potrebe). Bilo koji layer uvek može da proveri validnost tokena preko potpisa i može da mu veruje. Zaštita od zloupotrebe tokena je ovde vremenska, ali za hi-security u tokenData može da se ubaci neki counter operacija koji će se uvećavati pri svakoj server side autorizaciji i vraćati korisniku sa novim potpisom. Itd, itd...

Odgovor na temu