Teza de doctorat [621280]
Universitatea Tehnic ă din Cluj-Napoca
Teza de doctorat
Contribu ții în controlul accesului
bazat pe roluri în aplica ții de comer ț
electronic
Autor: ing. Mihaela Georgetta Ordean
Conduc ător știin țific: prof.dr.ing. Dorian Gorgan
– iulie 2008 –
2
3 CUPRINS
1 Introducere …………………………………. …………………………………………… ……………….9
1.1 Obiectivele tezei ……………………………. …………………………………………… ……….. 10
1.2 Structura tezei……………………………… …………………………………………… …………. 12
2 Starea actual ă a cercet ării în controlul accesului……………………. ……………………13
2.1 Primele modele în controlul accesului………….. ………………………………………….. 1 3
2.1.1 MAC – Mandatory Access Control ………………… …………………………………13
2.1.2 DAC – Discretionary Access Control…………….. ………………………………….14
2.2 Autorizarea în sisteme distribuite…………….. …………………………………………… … 14
2.3 Utilizarea rolurilor în sisteme distribuite …….. …………………………………………… . 15
2.4 Implement ări RBAC…………………………………….. ………………………………………. 16
2.5 Colective care au implementat modele RBAC………. …………………………………… 17
2.5.1 Colectivul de la George Mason University, SUA…… ……………………………17
2.5.2 Colectivul de la Imperial College, Londra ………. …………………………………18
2.5.3 Colectivul de la Western Ontario University, Canada …………………………..18
2.5.4 Colectivul de la Universitatea din Roma, Italia…. ………………………………..19
2.6 Standardiz ări în controlul accesului…………………….. …………………………………… 19
3 Modelul SCAR-ACE pentru controlul accesului bazat p e roluri ……………………21
3.1 Defini ții și termeni utiliza ți ………………………………………….. ………………………… 21
3.2 Componentele modelului ……………………….. …………………………………………… … 24
3.2.1 Nucleul …………………………………….. …………………………………………… ……24
3.2.2 Ierarhiile de roluri …………………………. …………………………………………… …26
3.2.3 Rela țiile statice………………………………… …………………………………………… 28
3.2.4 Rela țiile dinamice ……………………………….. ………………………………………..29
3.2.5 Extensiile ………………………………….. …………………………………………… ……30
3.3 Modele conceptuale …………………………… …………………………………………… ……. 32
3.3.1 Modele RBAC conceptuale………………………. …………………………………….32
3.3.2 Modele SCAR-ACE conceptuale …………………… ………………………………..33
3.3.3 Modelul de baz ă SCAR-ACE 0…………………………………………… …………….33
3.3.4 Definirea formal ă a modelului SCAR-ACE 0……………………………………….34
3.3.5 Ierarhiile de roluri și abordarea acestora în SCAR-ACE 1………………………35
3.3.6 Definirea formal ă a modelului SCAR-ACE 1……………………………………….35
3.3.7 Modelul constrângerilor în SCAR-ACE 2…………………………………………… 35
3.3.8 Definirea formal ă a modelului SCAR-ACE 2……………………………………….36
3.3.9 Modelul SCAR-ACE 3…………………………………………… ………………………37
3.4 Analiza constrângerilor………………………. …………………………………………… ……. 38
3.4.1 Prerechizite ………………………………… …………………………………………… …..39
3.4.2 Separarea îndatoririlor………………………. …………………………………………… 39
3.4.3 Cardinalitate……………………………….. …………………………………………… …..40
3.4.4 Constrângerile modelului ……………………… ………………………………………..40
3.5 Privilegiile ………………………………… …………………………………………… …………… 42
3.5.1 Specificarea nivelelor de acordare a privilegiilor . ………………………………..43
3.5.2 Nivele de securitate în acordarea privilegiilor…. ………………………………….43
3.5.3 Politica de acordare a privilegiilor…………… ……………………………………….49
3.5.4 Algebra politicii de acordare a privilegiilor …… …………………………………..50
3.6 Creden țiale ……………………………………….. …………………………………………… …… 51
3.6.1 Componentele unui creden țial ………………………………………… ……………….51
3.6.2 Prelucrarea creden țialelor…………………………………….. …………………………52
3.7 Rolul interfe țelor grafice utilizator ………………………. ………………………………….. 54
4 3.8 Controlul accesului ………………………….. …………………………………………… ……… 56
3.8.1 Ma șina de stare ………………………………… …………………………………………..5 6
3.8.2 Rolurile……………………………………. …………………………………………… …….57
3.8.3 Constrângeri ale rolurilor și ale asign ărilor utilizator ……………………………58
3.9 Definirea formala a modelului …………………. …………………………………………… .. 58
3.9.1 Defini ții și termeni …………………………………… ……………………………………58
3.9.2 Definirea regulilor………………………….. …………………………………………… ..61
3.9.3 Exemplificare……………………………….. …………………………………………… …62
3.9.4 Consisten ța specific ării modelului……………………………….. …………………..66
3.10 Fazele specific ării modelului ……………………………….. ………………………………… 68
3.10.1 Faza de analiz ă static ă…………………………………………… …………………….69
3.10.2 Faza de verificare / actualizare ………………. ……………………………………..70
3.10.3 Faza de planificare ………………………….. ………………………………………….72
3.10.4 Definirea mașinii de stare……………………………….. ……………………………73
3.10.5 Interfa ța utilizator grafic ă…………………………………………… ………………..74
3.10.6 Faza de rulare………………………………. …………………………………………… .75
4 Analiza aplica țiilor de comer ț electronic și implementarea modelului SCAR-
ACE………………………………………… …………………………………………… ………………..77
4.1 Introducere …………………………………. …………………………………………… …………. 77
4.2 Lan țul valoric ………………………………….. …………………………………………… …….. 77
4.2.1 Atragerea clien ților ……………………………………….. ………………………………78
4.2.2 Interac țiunea cu clien ții …………………………………………. ……………………….78
4.2.3 Ac ționarea la instruc țiunile clientului ……………………………. ………………….78
4.2.4 Reac ția la cererile clien ților……………………………………….. ……………………79
4.3 Modele de afaceri ……………………………. …………………………………………… ……… 79
4.3.1 Similarit ăți și diferen țe la nivel de segment ………………………… ……………..80
4.3.2 Participan ți la sistem …………………………………. …………………………………..80
4.4 Asigurarea intimit ății clientilor ……………………………….. ……………………………… 82
4.4.1 Platforme pentru preferin ța intimit ății …………………………………………. ……82
4.4.2 Cookies…………………………………….. …………………………………………… ……83
4.4.3 Tranzac ții electronice securizate…………………….. ………………………………..84
4.5 Arhitecturi func ționale ale aplica țiilor de comer ț electronic………………………….. 84
4.5.1 Idei arhitecturale de baz ă…………………………………………… ……………………84
4.5.2 Modele de încredere………………………….. …………………………………………..8 5
4.5.3 Arhitecturi sistem…………………………… …………………………………………… ..85
4.6 Implementarea modelului SCAR-ACE………………. …………………………………….. 89
4.6.1 Prezentarea arhitecturii……………………… …………………………………………… 89
4.6.2 Fluen ța tranzi țiilor………………………………………. …………………………………91
4.6.3 Func ționalit ăți implementate ………………………………. …………………………..91
4.6.4 Platforma de comer ț electronic…………………………………. ……………………..91
4.6.5 Structura aplica ției. Nivelele prezentare și de control al fluen ței…………….92
4.6.6 Structura datelor……………………………. …………………………………………… …97
4.6.7 Nivelul de logic ă și nivelul de date……………………………. ……………………..99
4.6.8 Nivelul de acces la date (DAL)………………… …………………………………….103
5 Rezultate experimentale ………………………. …………………………………………… …….105
5.1 Teste de performan ță …………………………………………… ……………………………… 105
5.1.1 Descrierea testelor………………………….. …………………………………………… 106
5.1.2 Interpretarea rezultatelor ……………………. …………………………………………107
5.2 Teste de scalabilitate……………………….. …………………………………………… …….. 108
5.2.1 Interpretarea rezultatelor ……………………. …………………………………………109
5 5.3 Teste de r ăspuns la atac simulat ………………………… ………………………………….. 111
5.4 Teste de conformitate cu cerin țele modelului SCAR-ACE ……………………….. .. 112
6 Concluzii și dezvolt ări ulterioare ……………………………….. …………………………….115
6.1 Contribu ția proprie………………………………….. ………………………………………….. 1 15
6.2 Dezvoltari ulterioare ………………………… …………………………………………… ……. 116
Anexa 1 Bibliografie…………………………. …………………………………………… …………….119
6 Lista figurilor
Figura 1. Rela ția intre utilizator, rol și permisiuni………………………………… …………. 11
Figura 2. Nucleul RBAC ……………………….. …………………………………………… ……… 24
Figura 3. Componentele modelului SCAR-ACE………. …………………………………….. 26
Figura 4 Exemple de ierarhii de roluri: a) arbore; b) arbore invers; c) latice…………. 27
Figura 5. Modele RBAC conceptuale ……………… …………………………………………… . 33
Figura 6. Exemplu de ierarhie de roluri………… …………………………………………… ….. 38
Figura 7. Ierarhia de roluri SCAR-ACE………….. …………………………………………… .. 41
Figura 8. Use case de înregistrare/login a unui viz itator……………………………………. 44
Figura 9. Diagrama de clase: Interfe țe pentru selectarea rolurilor…………………. ……. 45
Figura 10. Diagrama de stare ce denot ă controlul accesului în autentificare …………. 4 6
Figura 11. Diagrama de secven ță pentru determinarea creden țialului………………….. 47
Figura 12. Diagrama de colaborare în autentificare. …………………………………………. 48
Figura 13. Informa țiile liniei de comand ă…………………………………………… …………. 52
Figura 14. Diagrama de procesare a creden țialului…………………………………….. ……. 53
Figura 15. Modelul de comunicare al interfe țelor inteligente …………………………….. 54
Figura 16. Trei tipuri de sisteme de feedback…… …………………………………………… .. 55
Figura 17. Exemplu de ma șin ă de stare pentru selectarea a dou ă obiecte în vederea
compar ării lor…………………………………….. …………………………………………… ……….. 64
Figura 18. Fazele analizei de specificare a modelul ui ………………………………………. 69
Figura 19. Intr ările și iesirile fazei de analiz ă static ă………………………………………… 70
Figura 20. Intr ările și iesirile fazei de verificare / actualizare ……. ………………………. 71
Figura 21. Intr ările și ie șirile fazei de planificare ……………………. ………………………. 73
Figura 22. Datele de intrare/ie șire ale ma șinii de stare ……………………………….. ……. 74
Figura 23. Ma șina de stare pentru exemplul din figura 17……… …………………………. 74
Figura 24. Faza de realizare a interfe ței grafice cu utilizatorul ……………………. …….. 75
Figura 26. Arhitectura 1: Vedere fizic ă…………………………………………… …………….. 87
Figura 27. Arhitectura 1: Vedere logic ă…………………………………………… ……………. 87
Figura 28. Arhitectura SET……………………. …………………………………………… ………. 88
Figura 29. Arhitectura fizic ă cu SecureLink………………………………. …………………… 89
Figura 30. Procesul de achizi ție …………………………………………. ………………………… 89
Figura 32. Arhitectura logic ă…………………………………………… ………………………….. 90
Figura 33. Structura pe nivele a aplica ției ………………………………………… ……………. 93
Figura 34. Comunicarea utilizator – componenta de c ontrol a fluentei ………………… 95
Figura 35. Comunicarea WFL – BLL……………… …………………………………………… . 96
Figura 36. Structura aplica ției. Nivelele de logic ă și de acces la date ………………….. 99
Figura 39. Timpii la autentificarea utilizatorilor …………………………………………… ..107
Figura 40. Timpii la terminarea sesiunii utilizator …………………………………………… 107
Figura 41. Use case pentru testarea scalabilit ății …………………………………………. ….109
Figura 42. Rezultatele testului 1 de scalabilitate. …………………………………………… ..110
Figura 43. Rezultatele testului 2 de scalabilitate. …………………………………………… ..110
Figura 44. Variatia timpilor totali de executile in aplicatia scalata………………………111
7 Lista tabelelor
Tabelul 1. Predicate de specifica ție…………………………………………. ……………………. 59
Tabelul 2. Predicate de planificare……………. …………………………………………… …….. 60
Tabelul 3. Predicate de execu ție …………………………………………. ……………………….. 60
Tabelul 4. Gestionarea st ărilor la ac ționarea butonului Back……………………….. ……101
8
9 1 Introducere
Controlul accesului are drept obiectiv protejarea r esurselor fa ță de accesul
neautorizat si se realizeaza prin acordarea de perm isiuni. Un sistem de control al
accesului implic ă o politic ă prin care se specific ă cine poate accesa o anumit ă resurs ă
și în ce manier ă o poate face. Politicile sunt în general exprimate prin starea curent ă a
sistemului și st ările care pot rezulta din aceasta. In momentul în c are sistemul de
control al accesului este perceput ca și un sistem de tranzi ții între st ări, acesta const ă
din setul de st ări, regulile de tranzi ții între st ări și un set de propriet ăți sau interog ări
care sunt de interes într-o anumit ă stare (vezi si 3.1.).
În Internetul de ast ăzi exist ă un num ăr din ce in ce mai mare de aplica ții care
necesit ă decizii de autorizare. Aceste aplica ții includ (dar nu sunt limitate la) comer țul
electronic, gestionarea și partajarea resurselor distribuite, execu ția și desc ărcarea de
cod de la distan ță (exemplu: applet-uri Java și controale ActiveX). Autorizarea acestor
aplica ții este semnificativ diferit ă de cea a sistemelor centralizate și chiar de cea a
sistemelor distribuite relativ mici. În sistemele d e autorizare pe Internet exist ă mai
multe entit ăți, multe dintre acestea necunoscându-se una pe ceal alt ă și, de multe ori,
neexistând o autoritate central ă de încredere pentru to ți actorii. Regulile conform
cărora se realizeaz ă deciziile de acordare a controlului pot necesita m odific ări ale
acestor aplica ții, deciziile pentru permiterea accesului la o resu rsă specific ă depinzând
de tipul aplica ției. Din acest motiv exist ă diferite politici pentru a se realiza controlul
accesului.
Odat ă cu extinderea Internetului, calculatoarele individ uale care initial erau
protejate prin politici locale de control al accesu lui, sunt interconectate și acceseaz ă
resurse atât local cât și de la distan ță. Astfel atat num ărul resurselor care pot fi
accesate a crescut cat și num ărul utilizatorilor care acceseaz ă aceste resurse.
Controlul bazat pe roluri este un concept neutru de politici pentru obtinerea
controlului accesului. Au fost propuse diferite mod ele de-a lungul timpului precum
modelele de control al accesului discret și cel obligatoriu (Discretionary Access
Control – DAC – și Mandatory Access Control – MAC), modelul Clark-Wi lson,
modelul de control al accesului bazat pe roluri (Ro le Based Access Control – RBAC)
și bazat pe actiuni (Task Based Model – TBAC). Mode lul de referin ță în controlul
accesului bazat pe roluri este RBAC [FGS01], [SCH +96]. In cadrul RBAC
permisiunile de acces nu sunt asignate în mod direc t utilizatorilor ci abstractiz ării
cunoscute sub denumirea de “rol”. Au fost propuse d iferite extensii dintre care dou ă
sunt semnificative: una concentrându-se pe specific area constrângerilor [SC96], iar
cealalt ă descriind un cadru pentru delegarea autorit ății prin intermediul rolurilor
administrative [SBM98].
RBAC este un model relativ recent pentru controlul accesului, care poate
gestiona în mod dinamic seturi de utilizatori și resurse. Acest model simplific ă
anumite aspecte ale politicii de administrare și furnizeaz ă un mijloc de luare a
deciziilor pentru controlul accesului.
In cadrul modelelor conven ționale existente (amintite mai sus), de control al
accesului bazat pe roluri, accesul la resurse se re alizeaz ă de c ătre utilizatori certificati
de catre un inginer de sistem. Aceste modele nu sun t adecvate sistemelor deschise și
10 descentralizate în care utilizatorii sunt anonimi și identitatea acestora nu este
cunoscut ă a priori.
Pentru sistemele deschise s-au propus metode de con trol al accesului bazate pe
creden țiale care implementeaz ă no țiunea de access binar bazat pe încredere. Astfel,
dac ă un utilizator câ știg ă încrederea pe baza unui creden țial va fi admis în sistem și va
avea acces la resursele acestuia iar, în caz contra r, nu i se va accorda accesul.
Un sistem de control al accesului este totodat ă și o instan ță a unei scheme de
control al accesului si specific ă tipurile de reguli relativ la tranzi țiile între st ări
[TL04]. Un exemplu de model pentru controlul accesu lui este modelul bazat pe
matrici de acces [GD75]. In cadrul acestui model un utilizator ini țiaz ă ac țiuni sau
opera ții asupra obiectelor, iar acestea (ac țiunile sau opera țiile) sunt acceptate sau
respinse în func ție de autorizarea specificat ă în sistem . Matricea de acces este un
model conceptual care specific ă drepturile pe care le are fiecare utilizator asupr a
fiec ărui obiect. Acest model se utilizeaz ă în special in sistemele de operare [TAP +05].
1.1 Obiectivele tezei
Lucrarea de fa ță se refer ă la un domeniu particular al autoriz ării și propune
modelul SCAR-ACE pentru controlul accesului bazat p e roluri în aplica ții de comer ț
electronic.
Pe m ăsur ă ce cre ște complexitatea aplica țiilor sunt necesare politici noi de
administrare și control al accesului. Aplica țiile de comer ț electronic devin din ce în ce
mai complexe, impunand accesul la resurse heterogen e a utilizatorilor cu roluri
diferite. Controlul accesului în aplica țiile de comert electronic este un subiect
important al cercetarii stiintifice actuale.
(1) Direc ția de cercetare
În [B05] sunt definite direc țiile de cercetare pentru modelele, arhitecturile și
tehnologiile de control al accesului. Teza se subsc rie unei direc ții și anume realizarea
unui model care s ă suporte controlul accesului într-un sistem distrib uit. SCAR-ACE
extinde abordarea propus ă în [B05] prin utilizarea ma șinilor de stare.
(2) Problema de rezolvat
Unul dintre obstacolele privind accesul pe Web la r esurse îl reprezint ă
inabilitatea de a gestiona autorizarea într-o manie r ă eficient ă si fara costuri relativ
mari, in ce priveste timpul si banii. In [PSA01] se prezinta dou ă solu ții de
implementare RBAC de control al accesului pe Web. A mbele solu ții sunt modele
bazate pe cookies, lasand astfel deschisa o bre șă în securitate.
Lucrarea de fa ță își propune realizarea unui model sigur de control al accesului
bazat pe roluri și care s ă abordeze dintr-o perspectiv ă diferit ă controlul accesului fara
a utiliza cookies. Modelul propus permite doar util izatorilor autoriza ți s ă acceseze
resursele sistem, printr-un control bazat pe ierarh ii de roluri si printr-o gestionare a
rolurilor mutual exclusive.
Un alt obiectiv al lucrarii este modelarea in RBAC a fluxului de control a
accesului în aplica țiile distribuite.
11 (3) Solu ția propus ă
Pentru a controla într-o aplica ție distribuita fluen ța și accesul la resurse se
introduce no țiunea de rol [L97] ca un element intermediar între utilizator și setul de
permisiuni ale acestuia (vezi figura 1).
Fiec ărui rol i se ata șeaz ă un set de permisiuni (reg ăsite în unele accep țiuni sub
denumirea de privilegii) de acces la opera ții și resurse.
Figura 1 ilustreaz ă accesul utilizatorilor (vezi și 2.1, 4.1.) la opera ții și resurse
prin intermediul rolurilor în SCAR-ACE:
Figura 1. Rela ția intre utilizator, rol și permisiuni
Săgeata dubl ă ilustreaz ă o rela ție de n-m între utilizator și rol, rol și ma șina de
stare, ma șina de stare și permisiuni.
Scopul oric ărui mecanism de control al accesului este de a prot eja resursele. În
termenii modelului SCAR-ACE resursele reprezinta ob iecte: fi șiere, date, înregistr ări,
tabele într-un DBMS sau opera ții. Atât modelul formal cât și cel func țional al SCAR-
ACE utilizeaz ă ma șini de stare pentru realizarea controlului accesulu i.
Modelul SCAR-ACE are urm ătoarele func ționalit ăți necesare realiz ării
controlului accesului:
– asocierile utilizator/rol: reprezinta utilizatorii autoriza ți s ă realizeze
un anumit rol;
– constrângeri de tipul separarea îndatoririlor (asoc ieri de tip utilizator
/ rol care indic ă conflict de interese):
o constrangeri statice (Static Separation of Duties – SSD –
vezi și 2.3.3): un utilizator nu poate fi autorizat pentr u dou ă
roluri (de exemplu recep ționer al cererii și furnizor de
bunuri);
o constrângeri dinamice (Dynamic Separation of Duties –
DSD – vezi și 2.3.4): un utilizator poate fi autorizat pentru
dou ă roluri dar nu poate ac ționa simultan în ambele (de
exemplu vânz ător și cump ărător al aceluia și produs). Utilizator
Rol
Permisiuni Ma șina de
stare
Operatii Resurse
12 1.2 Structura tezei
Teza este structurat ă în sase capitole în care este descris atât modelul cât și
partea de validare a acestuia pentru o aplica ție de comer ț electronic.
Capitolul întâi contine introducerea în domeniul si stemelor de control al
accesului și obiectivele tezei.
Capitolul al doilea este destinat stadiului actual al cercet ării în domeniul tezei și
contine descrierea primelor modele pentru controlul accesului și implement ările
curente. Totodat ă sunt trecute în revist ă colectivele care se ocup ă de modele de
control al accesului.
Capitolul al treilea con ține descrierea modelului SCAR-ACE. Sunt defini ți
termenii care sunt utiliza ți în cadrul lucr ării dup ă care se detaliaz ă componentele
modelului SCAR-ACE în compara ție cu modelul de referin ță RBAC, respectiv
SCAR-ACE 0, SCAR-ACE 1, SCAR-ACE 2 și SCAR-ACE 3. In acest capitol este
descris modelul SCAR-ACE, prin analiza constrângeri lor, desemnarea privilegiilor și
nivelele de acordare a privilegiilor, nivelele de s ecuritate, politica și algebra politicii
de acordare a privilegiilor. Capitolul detaliaz ă modul în care se realizeaz ă controlul
accesului în SCAR-ACE. In acest scop sunt descrise componentele pe care se bazeaz ă
controlul accesului respectiv ma șina de stare, rolurile și constrângerile. Este analizat
modelul formal pentru controlul accesului în SCAR-A CE si fazele de realizare a
acestuia.
Urm ătorul capitol este destinat validarii modelului SCA R-ACE. Astfel, în
capitolul al patrulea sunt analizate componentele și arhitecturile aplica țiilor de comer ț
electronic, modelele de afaceri în comer țul pe Internet și asigurarea intimit ății în
cadrul aplica țiilor de comer ț electronic. Se detaliaza implementarea prin care s e
valideaz ă modelul SCAR-ACE. Astfel este descris ă arhitectura aplica ției de comer ț
electronic implementat ă si structura aplica ției.
Rezultatele experimentale si testele efectuate sunt prezentate in capitolul al
cincilea.
In capitolul sase sunt prezentate concluziile și dezvolt ările ulterioare ale
modelului.
Anexa întâia con ține bibliografia.
13 2 Starea actual ă a cercet ării în controlul accesului
Acest capitol examineaz ă tehnologiile și cercet ările realizate în control
accesului. Voi începe cu o trecere în revist ă a primelor modele pentru controlul
accesului urmat ă de o introducere în RBAC în care se vor descrie pe scurt conceptele
de baz ă și extensiile disponibile. Apoi vor fi prezentate ce le mai cunoscute
implement ări ale modelului de baza RBAC și colectivele implicate în dezvoltarea de
sisteme de control al accesului.
2.1 Primele modele în controlul accesului
Inc ă din 1960 controlul accesului a fost un subiect de interes în special în
managementul bazelor de date și în sistemele de operare. Obiectivul acestuia era, pe
de o parte, cel de a proteja resursele sistemului f a ță de accesul neautorizat si, pe de
alt ă parte, de a permite accesul autorizat.
Primele modele în domeniul controlului accesului au fost: Mandatory Access
Control (MAC) și Discretionary Access Control (DAC).
2.1.1 MAC – Mandatory Access Control
MAC a fost introdus in domeniile militar și guvernamental, realizând controlul
accesului prin introducerea de etichete de securita te. Acest model, formalizat ini țial de
Bell și LaPadula [BL75], ata șeaz ă etichete sau clasific ări de securitate fiec ărui obiect.
Deoarece diferitele forme ale modelului Bell-LaPadu la, determinate de multe
varia țiuni, au dus la confuzii, Sandhu introduce un model minimal [S93] numit BLP
care încapsuleaz ă p ărțile esen țiale ale modelului Bell-LaPadula.
In MAC accesul este garantat pe baza etichetelor de securitate ata șate
subiectelor sau obiectelor. Denotarea etichetelor d e securitate era λ(s) și respectiv
λ(o). Aceste etichete de securitate formeaz ă o latice asupra c ăreia se poate aplica
rela ția de ordine par țial ă ≤.
Deoarece MAC a fost dezvoltat pentru domeniul milit ar, confiden țialitatea este
importanta, si se ob ține prin restric ții de fluen ță între obiecte sau între diferite grupuri
de securitate. Aceste restric ții se exprim ă prin urm ătoarele dou ă propriet ăți:
– proprietatea de securitate simpl ă, cunoscut ă ca și „no read up”, impune ca
un subiect s ă poat ă citi un obiect dac ă λ(o) ≤ λ(s);
– proprietatea *, sau „no write down”, permite unui s ubiect s ă scrie un
obiect numai dac ă λ(s) ≤ λ(o). Aceast ă proprietate se adreseaz ă
„sc ăpărilor” de informa ții de c ătre programe mali țioase. Prin aceast ă
proprietate nu se permite programelor s ă scrie informa ții în obiecte care ar
putea fi citite de c ătre subiec ți cu privilegii de securitate sc ăzute.
Proprietatea * permite a șadar scrierea obiectelor care au aceea și etichet ă
de securitate ca și utilizatorii, adic ă exprimat formal: λ(s) = λ(o).
Administratorii de re țea sunt responsabili pentru între ținerea etichetelor de
securitate; astfel, nici un alt utilizator nu poate schimba aceste etichete. Ori de câte ori
un obiect este dublat acestuia i se ata șeaza o etichet ă de securitate identica cu cea a
obiectului initial.
14 Un model MAC similar cu BLP a fost publicat de Biba [B75]. Spre deosebire de
BLP, modelul lui Biba î și propune ob ținerea integrit ății datelor prin metode opuse
confiden țialit ății. Acest model permite fluen ța datelor numai dinspre date cu
integritate înalt ă c ătre date cu integritate sc ăzut ă, exact invers accesului din modelul
BLP.
Modelele MAC sunt îns ă destul de rigide. Acestea suport ă un set fix de clase de
securitate și permit doar administratorilor de sistem s ă modifice politica de securitate.
2.1.2 DAC – Discretionary Access Control
DAC î și are originile în aria academic ă. El permite sau restric ționeaz ă accesul la
un obiect pe baza identit ății utilizatorului care îl acceseaz ă. Utilizatorilor le este
permis accesul prin permisiuni asupra obiectelor pr oprii. Totodat ă utilizatorilor le este
permis s ă delege drepturile proprii altor utilizatori. Un ex emplu clasic de DAC este
Access Control List (ACL) în care obiectele sunt as ociate la o list ă de utilizatori (care
formeaza grupuri) c ărora le este permis accesul.
Intr-o aplica ție static ă, în care accesul nu depinde de ac țiuni anterioare, accesul
la toate obiectele pentru to ți utilizatorii se poate reprezenta printr-o matrice . Aceast ă
matrice, denumit ă matrice de acces [L71], [S92], are câte un rând pe ntru fiecare
utilizator și o coloan ă pentru fiecare obiect. Elementele matricii memorea ză drepturile
de acces ale unui utilizator individual pentru un a numit obiect. Aceast ă matrice poate
avea dimensiuni enorme și, de obicei, este rar populat ă. Opera ția de control al
accesului include dezvoltarea și reprezentarea acestei matrici. In sistemele de co ntrol
al accesului, aceast ă matrice a fost implementat ă în diferite moduri:
– memorat ă pe coloane astfel încât fiecare coloan ă este o list ă. Acesta este
modelul ACL (Access Control List);
– memorat ă pe linii și fiecare linie cunoscut ă sub denumirea de capabilit ăți.
Astfel de capabilit ăți memoreaz ă o list ă a privilegiilor acordate fiec ărui
subiect;
– prin memorarea doar a celulelor utile ale matricii împreun ă cu pozi ția
acestora în matrice.
Aceste abord ări au avut atât avantaje cât și dezavantaje. Problemele apar de
obicei la inserarea de utilizatori, la ștergerea anumitor utilizatori existen ți sau la
crearea și ștergerea obiectelor. De exemplu, în cazul listelor de control al accesului,
ștergerea unui utilizator implica verificarea fiec ărei liste din sistem. In organiza țiile în
care atât utilizatorii cât și obiectele de protejat se modific ă frecvent, DAC s-a dovedit
a fi neadecvat.
2.2 Autorizarea în sisteme distribuite
Una dintre primele implement ări în domeniul autoriz ării în sisteme distribuite
este Grapevine [BLN82] in care serverele determin ă dac ă un client este membru al
unui grup autorizat. O abordare similar ă se reg ăse ște în Sun Yellow Pages unde
fi șierele gestionate centralizat (precum etc/group ) sunt consultate in prin autorizarea
utilizatorilor. În ambele cazuri, cu toate c ă deciziile de autorizare se realizeaz ă local,
clientul trebuie s ă ob țin ă datele de autorizare de la un server aflat la dist an ță.
15
Un alt model de autorizare pentru sistemele distrib uite este Kerberos [MN88].
Acest model se bazeaz ă pe principiul c ă fiecare utilizator este autorizat pentru un
numar de servicii și fiecare serviciu î și gestioneaz ă utilizatorii proprii. Scopul
sistemului de autentificare Kerberos este de a perm ite serviciilor s ă implementeze
modele diferite de autorizare prin care se permite accesul utilizatorilor. Determinarea
utilizatorilor autorizati se realizeaza pe baza unu i tichet specific fiecarui serviciu.
Proiectul SESAME [M95], [PP95] extinde sistemul de autorizare Kerberos și
define ște o schem ă pentru propagarea sigur ă a privilegiilor, inclusiv roluri și grupuri,
de la clien ți la serverele de aplica ție.
Alte sisteme propuse ofer ă solu ții de autorizare off-line, precum delegarea
certificatelor în Arhitectura de Securitate a Siste melor Digitale Distribuite [GGK+89],
[GM90], mecanismul de autentificare în cascad ă a lui Sollins [S88], autorizarea
proxy-based a lui Neuman [N93] și autorizarea bazat ă pe certificate a lui Woo and
Lam [WL98].
2.3 Utilizarea rolurilor în sisteme distribuite
Conceptul de roluri se utilizeaz ă în aplica țiile software din anii ‘75, dar abia
dup ă 1990 autorizarea bazat ă pe roluri s-a maturizat în modelul RBAC. Acest mod el
vine ca și o completare a modelelor MAC și DAC și este definit prin intermediul
entit ăților urm ătoare [S96]: utilizatori, roluri, ierarhii de rolur i, permisiuni și
constrângeri.
Rădăcinile RBAC includ utilizarea grupurilor în UNIX și alte sisteme de
operare, si gruparea bazata pe privilegii în sistem ele de gestionare a bazelor de date.
Modelul RBAC încapsuleaz ă toate aceste no țiuni într-un model unic în termeni de
roluri și ierarhii de roluri, activarea rolurilor și constrângeri asupra rolului pe
utilizator.
O constrângere tipic ă de autorizare, recunoscut ă și relevant ă, este separarea
îndatoririlor (Separation of Duties – SoD) care se aplic ă asupra rolurilor, asign ării rol-
utilizator și asign ării rol-permisiuni.
În ultimii ani s-au implementat diverse mecanisme d e autorizare bazate pe roluri
în: managementul bazelor de date, managementul secu rit ății și sisteme de gestionare a
re țelelor.
Mecanismele de autorizare determin ă ca la autentific ări diferite ale unui
utilizator în cadrul aceleia și sesiuni de lucru, acestuia s ă i se asigneze de fiecare dat ă
un rol nou prin excluderea de la cel vechi. Adminis trarea securit ății bazate pe roluri
este simplificat ă datorit ă asign ării rol-permisiuni.
Primele eforturi pentru definirea unui standard pen tru tehnologiile de control al
accesului bazate pe roluri au fost raportate la wor kshop-ul ACM RBAC în 2000 de
catre Shandu si Ferraiolo. Atunci se pun bazele sta ndardului care a fost aprobat cu un
an mai târziu, de c ătre NIST (National Institute of Standards and Techn ology) în
autorizarea bazat ă pe roluri utilizând re țele Petri pentru elaborarea c ăruia au participat
28 de organiza ții.
16 Modelele și implement ările existente bazate pe roluri sunt relativ simila re în
conceptele fundamentale utilizate dar difer ă semnificativ în detalii. Similaritatile și
diferen țele nu sunt evidente deoarece modelele folosesc ter minologii diferite în
descrierea acelora și concepte. Deoarece controlul accesului bazat pe r oluri este o
tehnologie relativ nou ă și deoarece produsele și modelele vin din medii academice și
comerciale diferite nu prea exist ă un consens asupra denumirii p ărților constituente.
Controlul accesului bazat pe roluri este, de asemen ea, o tehnologie relativ complex ă și
sofisticat ă și tratarea acesteia ca un model unic este oarecum n erealist ă tocmai datorit ă
inexisten ței unui consens în abordarea acesteia. Un model uni c fie ar include fie ar
exclude prea mult prezen ța unui singur punct de vedere asupra unui spectru l arg de
tehnologii și variante.
2.4 Implement ări RBAC
In [B95] Barkley descrie o implementare RBAC într-u n limbaj de programare
obiectual. Fiecare rol este reprezentat printr-o cl as ă diferit ă. La rulare, obiectele rol
servesc ca și proxy-uri pentru aplica țiile care cer accesul la anumite permisiuni.
Abordarea din [B95] nu ia în considerare ierarhiile de roluri și constrângerile pe care
modelul SCAR-ACE le include și le implementeaz ă.
Sistemul hyperDRIVE [B97] utilizeaz ă standardul LDAP pentru a implementa
servicii de autentificare și control al accesului. Sistemul face uz de tehnolo gia Java
Applet. Applet-ul Java hyperDRIVE este înc ărcat într-un navigator și furnizează o
interfa ță pentru accesarea resurselor web protejate. Un serv er LDAP serve ște drept
depozit centralizat pentru informa țiile de autentificare și control al accesului.
Definirea ierarhiilor de roluri și a rolurilor mutual exclusive este suportat ă de atribute
LDAP cu scop special. Abordarea SCAR-ACE difer ă în concept și implementeaz ă
rolurile și privilegiile asociate acestora prin introducerea ma șinilor de stare.
Sistemul I-RBAC [TC97] implementeaza controlul acc esului în Intranet. O
caracteristică a I-RBAC este utilizarea paralel ă a ierarhiilor de roluri locale și globale.
Rolurile locale au permisiuni asupra resurselor loc ale de pe un anumit server. Rolurile
globale au permisiuni asupra a șa-numitelor resurse globale care au un identificato r
unic în cadrul Intranet și pot fi accesate global. I-RBAC nu permite definir ea rolurilor
mutual exclusive. Spre deosebire de aceast ă implementare, SCAR-ACE este un model
pentru aplica ții pe Internet care accept ă roluri globale și permite existen ța rolurilor
mutual exclusive.
In [G99] se descrie un mecanism RBAC bazat pe servl e ți Java. Se propune o
arhitectur ă denumit ă JRBAC-WEB care se bazeaz ă pe execu ția cererilor HTTP (GET,
PUT) utilizându-se un servlet Java de securitate. I mplementarea suport ă definirea
ierarhiilor de roluri și constrângerilor de separare a îndatoririlor. JRBA C-WEB
folose ște autentificarea HTTP. In mod op țional abordarea permite p ăstrarea sesiunilor
de lucru prin utilizarea cookies sau prin tehnici d e rescriere a URL-ului pentru servle ți
Java. SCAR-ACE nu utilizeaz ă servle ți Java (ci creden țiale) și nici cookies.
RBAC/Web [FBK98] este o implementare a unui servici u de control al
accesului bazat pe roluri pentru servere web. RBAC/ Web nu con ține un mecanism
specific de autentificare și suport ă ierarhii de roluri, constrângeri de cardinalitate și
17 separarea dinamic ă și static ă a îndatoririlor. Un server Web poate utiliza o ext ensie
pentru a accesa direct API-ul RBAC/Web sau s ă forwardeze apelurile c ătre scripturi
CGI. Modelul SCAR-ACE nu este un simplu serviciu ci o aplica ție care oferă o suit ă
de servicii și include autentificarea utilizatorilor pe baza de nume utilizator si parola.
2.5 Colective care au implementat modele RBAC
2.5.1 Colectivul de la George Mason University, SUA
Ravi Sandhu este unul dintre pionierii cercet ărilor in controlul accesului bazat
pe roluri. El, studen ții și colegii s ăi, au dezvoltat mai multe modele de control al
accesului și extensii ale acestora. In [M98] Sandhu, Ferraiolo și Kuhn revizuiesc cele
patru modele RBAC (vezi și 3.4) în încercarea de standardizare, dar descrier ea
modelelor realizat ă de acest colectiv r ămâne foarte general ă. In [FSG01] Ferraiolo et
al. descriu o propunere de standard RBAC printr-o s pecifica ție formal ă utilizând
nota ția Z.
Majoritatea modelelor RBAC în care a fost implicat Sandhu suport ă ierarhiile
de roluri. In [M98] autorii consider ă ierarhiile de roluri ca fiind o prerechizit ă în
realizarea constrângerilor de separare a îndatoriri lor.
Lucrarea [S00] este una dintre pu ținele care adreseaz ă câteva probleme ale
RBAC în sisteme distribuite. In acest articol autor ii furnizeaz ă câteva simul ări ale
modelelor prin utilizarea de entit ăți autonome care sunt administrate separat.
Sandhu și colectivul s ău se num ără printre pu ținii care au acordat aten ție
modului de administrare a RBAC și introduc astfel modelul ARBAC [SBC +97].
Majoritatea modelelor sunt cuprinz ătoare și bine specificate dar, cu toate
acestea, nu suport ă parametri. Parametrii ajut ă în abstractizarea rolurilor și
privilegiilor simplificand administrarea politicii de securitate. Necesitatea
parametrilor a fost recunoscut ă în [KS03].
Determinând necesitatea unui mecanism de control al accesului flexibil (care s ă
nu depind ă de aplica ție), în [BJS96] Jajodia si Bertino propun un model de control al
accesului care suport ă autoriz ările pozitive și negative. Acest model suport ă
autorizarea puternic ă (cea care este obligatoriu a fi realizat ă) precum și autorizarea
slab ă (pentru permiterea excep țiilor). In cadrul acestui model s-a realizat FAM
(Flexible Authorization Manager) [JSS +97], [JSS +01] care este un model formal de
for țare de politici de control al accesului multiplu în cadrul unui sistem. Acest model
utilizeaz ă predicate de tipul cando , do , predicate derivate de tipul dercando , done ,
error . Cu acestea se exprim ă ceea ce poate sau nu poate face un subiect. Deoare ce se
consider ă ambele politici (atât cea pozitiv ă cât și cea negativ ă), este luat ă în calcul și
rezolvarea conflictelor. Aceste modele nu sunt baza te pe roluri dar suport ă grupurile
și delegarea și au servit ca un fundament solid pentru RBAC.
In [SRJ01] se define ște FAF (Flexible Authorization Framework) care intr oduce
rolurile în timp ce este men ținut ă autorizarea pozitiv ă și negativ ă. In cadrul acestui
model este p ăstrat ă și no țiunea de grup.
FAF poate, de asemenea, considera istoricul accesul ui în luarea deciziilor, iar
suportul real pentru constrângeri a fost descris în [SRJ01]. Prin acest articol sunt
introduse constrângerile temporale și se evidentiaza validarea conceptului.
18 2.5.2 Colectivul de la Imperial College, Londra
Ponder este o implementare RBAC dezvoltat ă de Imperial College, Londra, de
către colectivul condus de Sloman și Lupu. Inaintea consider ării controlului accesului
bazat pe roluri colectivual a fost implicat în mana gementul politicilor de securitate
[S94]. Ulterior, s-au luat în considerare politici prin care se exprimau permisiuni și
obliga ții [L98], [LS99], [LS97]. S-au luat în calcul atât politici de securitate negative
cât și pozitive și s-a acordat o aten ție deosebit ă rezolv ării conflictelor prin reguli
bazate pe priorit ăți.
In [DDL +01], [D02] se descriu extensiile care includ grupar ea rolurilor și
suportul pentru delegarea autoritatii.
S-a ajuns la concluzia c ă specificarea politicilor de securitate pentru obie cte
individuale este ineficient ă și, pentru a rezolva aceast ă problem ă, s-au introdus
domeniile. Domeniile grupeaz ă obiecte și apartenența la un domeniu este explicit ă și
nu definit ă prin intermediul predicatelor.
Un punct tare al modelului Ponder provine din tipiz area obiectelor determinând
o politic ă extensibil ă și flexibil ă. Un exemplu de politic ă dezvoltat de acest colectiv si
descris printr-un limbaj de specificare a politicil or este ilustrat mai jos:
inst auth+ fileServerAccess {
subject /Employees;
target Servers/PrinterServer;
action *; // permite orice actiune
when Time.after(’’1300’’); // constrangere
}
Ponder suport ă trei tipuri de constrângeri. Constrângerile subiec t/ țint ă se refer ă
la atributele obiectelor subiect sau țint ă. Constrângerile parametrului
ac țiune/eveniment sunt expresii care utilizeaz ă parametri sau evenimente
fundamentale politicii. In final, sunt suportate co nstrângerile de timp prin utilizarea
bibliotecilor temporale.
2.5.3 Colectivul de la Western Ontario University, Canada
Nyanchama și Osborn au introdus modelul rolurilor sub forma de graf în
[NO94], în care se propune o modalitate de administ rare a rolurilor utilizându-se
teoria grafurilor. Modelul lor define ște rolurile ca și un set de privilegii determinate.
Din cauz ă c ă în cadrul acestui model nici rolurile și nici privilegiile nu sunt
parametrizate, este relativ simpl ă determinarea rela țiilor dintre roluri. Pentru a realiza
conectivitatea rolurilor în graf ei definesc MaxRole ca fiind rolul minim senior
comun, și MinRole ca fiind cel mai mare rol junior comun. Graful rol urilor se bazeaz ă
așadar pe o rela ție între rolurile junior și senior comune și este o latice limitat ă de
MinRole și MaxRole .
In [NO95] Nyanchama și Osborn rafineaz ă privilegiile pentru un model orientat
obiect. Ei, de asemenea, iau în considerare implica țiile apelurilor metodelor și
dependen ța între acestea.
In [NO99] Nyanchama și Osborn î și continu ă munca axându-se pe introducerea
managementului ierarhiei de roluri și investigheaz ă constrângerile. Ei clasific ă
constrângerile în cinci tipuri (utilizator-grup, ro l-rol, privilegiu-privilegiu, asignarea
utilizator-rol și asignarea rol-privilegiu). Aceste categorii sunt o expresie a separ ării
statice a îndatoririlor.
19 In [O97] se trateaz ă propriet ățile MAC pentru modelul rolurilor tratate prin
teoria grafurilor. Sunt considerate obiecte și subiecte cu asign ări de etichete de
securitate și se trateaz ă modul în care se pot construi ierarhiile de roluri . Acest efort
este extins [O02] prin introducerea de grafuri de f luen ță din grafurile de roluri.
2.5.4 Colectivul de la Universitatea din Roma, Ital ia
Giuri define ște rolurile ca un set de domenii protejate [G95], [ GI97]. Un
domeniu protejat este un set de privilegii, și identific ă setul tuturor opera țiilor care pot
fi efectuate de c ătre un subiect la un anumit moment de timp. Domenii le protejate au
fost introduse pentru a suporta separarea dinamica a îndatoririlor cum ar fi
constrângerea la nivelul privilegiilor (de exemplu interzicerea ca un subiect s ă aib ă
privilegii conflictuale în acela și timp).
Rolurile au fost definite ca și un set de privilegii și se suport ă ierarhiile de
roluri.
Pentru a se implementa separarea îndatoririlor, lim bajul propus permite and-
roles și or-roles . Rolurile and-roles specific ă un set de privilegii și roluri care pot fi
activate simultan, în timp ce rolurile or-roles definesc roluri mutual exclusive.
Modelul lor de baz ă (Named Set of Protection Domain) nu suport ă
constrângerile ci doar o extensie [G95] a acestora.
In [G98] Giuri și Iglio extind modelul propriu pentru a permite con trolul
accesului bazat pe con ținut. Ei au introdus privilegii restrictive care co n țin expresii
logice care trebuie satisf ăcute la momentul în care este utilizat un privilegi u. In acest
model ei introduc template-uri de roluri care sunt practic roluri parametrizate.
In [G98] Giuri analizeaz ă suportul politicii de securitate propuse în cadrul unei
aplica ții Java și cum poate fi extins ă aceasta politica pentru a suporta controlul
accesului bazat pe roluri.
2.6 Standardiz ări în controlul accesului
Modelele RBAC sunt luate ca și abordare general ă pentru controlul accesului.
Standardizarea RBAC (standard dezvoltat de NIST) es te organizat ă în dou ă
părți mari: un Model de referin ță și Specifica ția Func țional ă [HTTP4] . Modelul de
referin ță este definit ca și o colec ție de elemente de baz ă (ex.: utilizatori, roluri,
permisiuni, opera ții și obiecte) și rela ții (tipuri de func ții incluse în cadrul acestui
standard). NIST define ște de asemenea și scopul caracteristicilor RBAC incluse în
standard. Acestea acoper ă diferite aspecte: ierarhii de roluri, constrângeri statice SSD
și dinamice DSD. Modelul de referin ță mai define ște și un limbaj în termeni de seturi
de elemente și func ții.
Dar nu toate caracteristicile standard sunt încapsu late în dezvolt ările existente ci
exist ă diverse variante care utilizeaz ă anumite seturi ale acestor caracteristici.
Standardizarea RBAC a atras un interes m ărit. Astfel, rolurile au fost luate în
considerare începând cu elaborarea SQL3 și a Oracle versiunea 7 în cadrul sistemelor
de gestionare a bazelor de date. Acestea (rolurile) au fost de asemenea încorporate în
diverse produse comerciale fie în mod direct fie pr in concepte precum “grup de
utilizatori”. Rolurile mai sunt de asemenea utiliza te pentru administrare în sisteme de
operare și în re țele de calculatoare precum Windows NT a Microsoft și NetWare de la
Novell [HTTP5].
20
21 3 Modelul SCAR-ACE pentru controlul accesului
bazat pe roluri
3.1 Defini ții și termeni utiliza ți
Defini ția 1 (securitate): Securitatea în aplica țiile software se refer ă în principal la
autenticitatea, integritatea și confiden țialitatea datelor, informa țiilor și serviciilor. In
mediile actuale aceste caracterisitici sunt oferite din ce în ce mai mult, în mod
particular și în sistemele deschise și distribuite [TS02]. In mod corespunz ător, orice
mecanism de securitate trebuie s ă implementeze propriet ățile caracteristice unui
asemenea sistem. In principal exist ă dou ă categorii de mecanisme de securitate: (i)
protocoale de criptare și (ii) monitorizarea – ce include controlul accesul ui.
Defini ția 2 (criptografia): Criptografia este tehnologia de asigurare a control ului
accesului bazat ă pe chei asimetrice publice și private.
Defini ția 3 (controlul accesului): Controlul accesului este tehnica ini țiat ă pentru
protec ția sistemelor centralizate [SC01] care sunt conecta te prin canale sigure pentru
înregistrarea utilizatorilor și care sunt gestionate de c ătre un administrator. Recent s-
au întreprins cercet ări pentru adaptarea controlului accesului și în sistemele distribuite
și deschise [HTTP06], [LPL +03].
Defini ția 4 (sistem de control al accesului) : Un sistem de control al accesului este un
sistem stare-tranzi ție < Γ, Q, ├, Ψ>, în care Γ este un set de st ări, Q este un set de
interog ări, ├: ΓxQ → { true , false } se numeste rela ție de necesitate, iar Ψ este setul de
reguli de tranzi ții între st ări. O stare γ ∈ Γ con ține toate informa țiile necesare pentru
luarea unei decizii în controlul accesului la un mo ment dat. Rela ția de necesitate ├,
determin ă dac ă exist ă o interogare dintr-o anumit ă stare. Dac ă exist ă o interogare, q ∈
Q pentru o cerere de acces, γ ├ q înseamn ă c ă accesul lui q este permis din starea γ. O
regul ă de stare-tranzi ție ψ ∈ Ψ determin ă modul în care sunt schimbate st ările
[TL04].
Defini ția 5 (utilizator) : Un utilizator este o instan ță a unui client al sistemului SCAR-
ACE.
Defini ția 6 (rol) : Un rol într-o aplica ție de comer ț electronic poate reprezenta
competen țe concrete precum cele ale unui vânz ător, cump ărător sau administrator de
sistem. Un rol poate încapsula autoritatea și responsabilitatea unui actor. Autoritatea
și responsabilitatea sunt diferite de competen ță: o persoan ă poate s ă fie competent ă s ă
conduc ă câteva departamente dar are responsabilitatea de a conduce doar unul.
Rolurile pot reflecta asignarea unor îndatoriri. Un rol administrativ este un rol care
include permisiunea de a modifica setul de utilizat ori, rolurile sau permisiunile, sau s ă
modifice asignarea rolurilor la utilizatori.
Defini ția 7 (ierarhia de roluri) : Ierarhia de roluri este o rela ție par țial sau total
ordonat ă între roluri. Mo ștenirea în cadrul unei ierarhii de roluri implic ă moștenirea
permisiunilor rolurilor situate la nivel superior î n cadrul ierarhiei.
22 O ierarhie este o structur ă de roluri care reflect ă autoritatea și responsabilit ățile în
cadrul unei organiza ții. Prin conven ție rolurile cu mai mult ă autoritate (roluri senior)
sunt reprezentate în partea de sus a ierahiei iar c ele cu mai pu țin ă autoritate (roluri
junior) în partea de jos a diagramei.
Defini ția 8 (rol privat) : In general, rolurile private sunt roluri maxime î ntr-o ierarhie.
Defini ția 9 (grup) : Grupul este un set de utilizatori care fac parte din aceea și categorie
de roluri.
Defini ția 10 (permisiune) : O permisiune este aprobarea de acces la una sau m ai multe
resurse ale sistemului. Termenii de autorizare, drepturi de acces și privilegii sunt de
asemenea utiliza ți în conjunctie cu cel de permisiune.
Permisiunile sunt în general pozitive și confer ă proprietarului posibilitatea de a
efectua o ac țiune în cadrul sistemului. In literatur ă se întâlne ște și termenul de
permisiune negativ ă – cea care împiedic ă accesul [SCH +96]. In SCAR-ACE se
consider ă c ă împiedicarea accesului este mai degrab ă o constrângere decât o
permisiune negativ ă.
Modelul conceptual al SCAR-ACE accept ă mai multe interpret ări pentru permisiuni,
de la faptul c ă este permis accesul la un set de servicii, la cel în care unitatea de acces
este un câmp al unei înregistr ări.
Fiecare tip de sistem isi protejeaz ă resursele; de exemplu un sistem de operare î și va
proteja fi șierele, directoarele, dispozitivele, porturile prin opera ții precum citire,
scriere, execu ție iar un sistem DBMS î și va proteja rela țiile, tuplele, atributele și
vederile prin opera ții precum select, update, delete și insert.
Permisiunile se pot aplica fie unuia fie mai multor obiecte și pot fi extrem de specifice
precum permisiunea de citire a unui fi șier particular, sau permisiunea de citire a
tuturor fi șierelor apar ținând unui departament. Maniera în care permisiunil e
individuale sunt reunite într-o permisiune generic ă care poate fi atribuit ă unei entit ăți
depinde de implementare.
Defini ția 11 (privilegiu ): Privilegiile sunt permisiunile asignate unui rol .
Defini ția 12 (resurse) : Resursele sunt fi șiere, conexiuni în re țea, servicii, sau metode
ale obiectelor.
Defini ția 13 (sesiunea) : Sesiunea este o mapare între un utilizator și subsetul de roluri
care îi sunt asignate, și este activ ă un anumit interval de timp dup ă care expir ă. Un
utilizator stabile ște o sesiune în timpul c ăreia î și activeaz ă un subset al rolurilor al
căror membru este (membru direct sau indirect prin in termediul ierarhiei de roluri).
Permisiunile acordate utilizatorului sunt formate d in reuniunea tuturor permisiunilor
rolurilor activate în cadrul acelei sesiuni. O sesi une este asociat ă unui singur utilizator
iar un utilizator poate avea active mai multe sesiu ni concomitent.
Defini ția 14 (constrângere) : O constrângere este o limitare și se poate aplica
urm ătoarelor componente: rol, ierarhie de roluri, sesiu ne, grup. Exemple de
constrângeri pot fi considerate rolurile mutual exc lusive precum un vânz ător și un
cump ărător al aceluia și produs.
Defini ția 15 (cerere) : O cerere este interogarea de accesare a unei resu rse.
23
Defini ția 16 (autorizator, autentificare) : Autorizatorul este entitatea care poate s ă
acceseze o resurs ă. În mod tradi țional, când un autorizator prime ște o cerere, prima
dat ă identific ă emi țătorul acesteia. Autentificarea este ac țiunea de a determina
identitatea emi țătorului într-o manier ă unic ă. Cu alte cuvinte, autentificarea r ăspunde
întreb ării “cine a realizat aceast ă cerere?”.
Defini ția 17 (autorizare) : Autorizare este procesul prin care se realizeaza
autentificarea si controlul accesului. In mod tradi țional, autorizarea informa ției este
realizată de c ătre un serviciu. In cadrul aplicatiilor deschise si distribuite creearea și
gestionarea informa țiilor de autorizare se realizeaza în mod dinamic.
Defini ția 18 (Politica de securitate) : Politica de securitate a unui sistem desemneaz ă
privilegiile ce trebuie acordate utilizatorilor și condi țiile acord ării acestora. In
contextul controlului accesului, politicile de securitate sunt declara ții relativ la
condi țiile puse pentru accesul la date, informa ții sau servicii, respectiv se specific ă
pentru fiecare rol tipul de date și servicii la care are acces.
Pentru politica conceptual ă de securitate [BW04] introduce no țiunea de algebr ă a
politicii. Aceasta ofer ă operatori de nivel înalt, orienta ți pe seturi, precum: enumerare,
adunare, sc ădere , selec ție .
Defini ția 19 (rela ție) : O rela ție între un subiect și un domeniu se exprim ă în termenii
ac țiunilor permise sau interzise, ac țiuni care trebuie sau nu efectuate. De exemplu
rela țiile între roluri stabilesc modul de propagare a pe rmisiunilor între acestea (între
roluri). No țiunea de rela ție este în conexiune cu cea de constrângere pentru definirea
politicii de activare a permisiunilor.
Defini ția 20 (identitate) : În sistemele tradi ționale identitatea adesea reprezint ă un cont
utilizator cunoscut înaintea emiterii oric ărei cereri. Pentru aplica țiile Internet,
no țiunea de identitate devine problematic ă, termenul însemnând “cineva” (un
utilizator). Când se întâlne ște un utilizator necunoscut anterior, acesta este a sociat în
SCAR-ACE cu un vizitator.
Într-un scenariu în care un autorizator și o cerere nu au rela ții anterioare, cunoa șterea
numelui sau identit ății emitentului nu poate ajuta autorizatorul s ă ia o decizie.
Adev ărata proprietate necesar ă cuiva pentru identificare este un creden țial care
con ține mai mult decât identificarea utilizatorului.
Defini ția 21 (creden țial) : Creden țialele sunt p ărți digitale similare unei chei publice și
au anumite propriet ăți [BK03] care se refer ă la aspecte de identitate sau non-
identificative ale unui utilizator (precum aptitudi ni sau profesia). Emi ță torul
creden țialului este responsabil de corectitudinea aser țiunilor. Cand se inspecteaz ă un
creden țial se verific ă semn ătura și încrederea în emi ță torul acestuia. Creden țialele se
pot utiliza în sistemele distribuite și deschise.
In SCAR-ACE un creden țial con ține informa ții de determinare a identit ății
emi ță torului unei cererii pentru accesarea unei resurse cat si informatii despre tranzitia
de efectuat. Creden țialul este compus din identificator utilizator, rol , stare curent ă și
eveniment declan șator al cererii. Toate aceste date formeaz ă un creden țial necesar
acord ării permisiunii de a accesa o resurs ă.
24 Defini ția 22 (RBAC – Role Based Access Control) : Conceptul RBAC se refer ă la o
tehnologie care încapsuleaz ă termenii de roluri și ierarhii de roluri, activarea rolurilor,
și constrângeri asupra rolului per utilizator. Este definit prin urm ătoarele componente:
nucleul RBAC, ierarhiile RBAC, rela ții statice și dinamice și se detaliaz ă în 4 modele
RBAC 0, RBAC 1, RBAC 2 și RBAC 3 (vezi 3.2 și 3.3).
3.2 Componentele modelului
Componentele de baz ă ale modelului standard RBAC de control al accesulu i
bazat pe roluri sunt [FSG01]:
1. Nucleul RBAC;
2. Ierarhiile RBAC;
3. Rela ții statice;
4. Rela ții dinamice;
5. Extensii.
Modelului SCAR-ACE realizeaz ă abordarea componentelor RBAC într-o
manier ă original ă astfel încât s ă fie solu ționate aspectele legate de politica de
securitate prin utilizarea unor ma șini de stare.
3.2.1 Nucleul
Nucleul modelului SCAR-ACE este similar nucleului R BAC. Nucleul RBAC
încapsuleaz ă aspectele esen țiale ale modelului: unui utilizator i se asigneaz ă un rol și
utilizatorul prime ște permisiuni ca urmare a fapului c ă este membru al acelui rol.
Rela țiile utilizator-rol și rol-permisiuni au rangul n:m (many-to-many). Astf el,
aceluia și utilizator i se pot asigna mai multe roluri și un rol poate fi asignat mai multor
utilizatori. Nucleul mai include de asemenea și conceptul de sesiune utilizator care
permite activarea / dezactivarea rolurilor.
Figura 2. Nucleul RBAC
Utilizatori Roluri Asign ări utilizator
(AU)
Utilizator-
sesiuni Sesiune-
roluri Asign ări permisiuni
(AP)
Permisiuni
Sesiuni Obiecte Opera ții
25 Una dintre cerin țele RBAC este aceea ca utilizatorilor s ă le fie permis ă
exercitarea mai multor roluri.
Setul de elemente și rela țiile nucleului RBAC sunt definite în Figura 2. Nucl eul
RBAC include un set de șase elemente de baz ă și anume: utilizatori, roluri, sesiuni,
obiecte, opera ții și permisiuni. Modelul RBAC este definit prin utiliz atori individuali
cărora li se asigneaz ă roluri și prin roluri carora li se asigneaz ă permisiuni. Astfel,
rela țiile utilizatori-roluri și roluri-permisiuni sunt rela ții many-to-many. Prin
asign ările AU (utilizator-rol) și AP (rol-permisiuni) prin tranzitivitate, un utili zator
are anumite permisiuni. Figura 2 ilustreaz ă și rela țiile RBAC de asignare a
utilizatorilor (AU) și de asignare a permisiunilor (AP).
Modelul nucleului RBAC include un set de sesiuni un de fiecare sesiune este o
mapare între un utilizator și un subset activat de roluri pentru utilizatorul r espectiv.
Nucleul modelului SCAR-ACE este similar nucleului R BAC și con ține
urmatoarele elemente: utilizatori, roluri, sesiuni, permisiuni, opera ții și obiecte,
masina de stare și rela țiile dintre aceste elemente (vezi figura 4).
Un utilizator în SCAR-ACE este definit ca și o persoan ă cu toate c ă acest
concept poate fi extins pentru a include calculatoa re, re țele sau agen ți inteligen ți
autonomi.
Un rol este o func ție în contextul sistemului distribuit, cu o semanti c ă asociat ă,
care confer ă autoritate și responsabilitate utilizatorului c ăruia i s-a atribuit acel rol (de
exemplu de cump ărător sau vanz ător, recep ționer sau distribuitor).
O permisiune este aprobarea de a efectua o opera ție asupra cel pu țin unui obiect
SCAR-ACE.
O opera ție este forma executabil ă a unui modul program sau a unui set de
metode care, dupa invocare, efectueaz ă un anumit serviciu pentru utilizator. Tipurile
de opera ții și obiecte controlate de modelul SCAR-ACE depind de nivelul de detaliu
luat in considerare. De exemplu, la nivel de sistem de fi șiere, opera țiile pot include
citirea, scrierea și execuția; la nivel de sistem de gestionare a bazelor de d ate,
opera țiile pot consta din insert, delete, append și update iar pentru un sistem de comer ț
electronic pot fi vizualizare catalog de produse, s electare produs, adaugare produs în
co ș, plata produs, etc.
Un obiect este o entitate care con ține sau prime ște informa ții. Pentru modelul
SCAR-ACE, obiectele pot fi containere de informa ții (de exemplu cataloage sau
ma șini de stare).
Scopul mecanismului de control al accesului este pr otejarea resurselor
sistemului mai precis de protejare a obiectelor și opera țiilor.
O sesiune SCAR-ACE este o mapare dintre un utilizator si mai multe roluri,
adic ă un utilizator stabile ște o sesiune în cursul c ăreia el este asignat cel putin unui
rol, rol care activeaz ă un anumit subset al opera țiilor, opera ții specifice permisiunilor
sale. Fiecare utilizator este asociat unei singure sesiuni deci este o rela ție de 1:1 între
sesiune și utilizator. Func ția sesiune-roluri ilustreaz ă rolurile activate în cadrul unei
sesiuni iar rela ția dintre sesiune și roluri este una de n:m.
Permisiunile unui utilizator sunt permisiunile asig nate rolurilor activate de c ătre
utilizator în timpul unei sesiuni.
Fiecare rol are ata șat ă o ma șin ă de stare specific ă doar modelului SCAR-ACE.
Rela ția dintre mașina de stare și roluri este de 1:1 adic ă fiec ărui rol îi corespunde una
și numai una dintre ma șinile de stare. Rela ția dintre ma șina de stare și permisiuni este
de 1:n în sensul c ă unei ma șini de stare îi corespund mai multe permisiuni, pri n
tranzitivitate cele specifice rolului pe care îl de scrie.
26
Figura 3 . Componentele modelului SCAR-ACE
Accesul unui rol la un set de permisiuni nu poate a vea loc decât prin intermediul
ma șinii de stare aceasta fiind o diferent ă major ă fa ță de modelele existente.
Rela țiile dintre elemente fac parte din model, unele din tre acestea fiind diferite
în SCAR-ACE fa ță de RBAC. Modelul SCAR-ACE impune constrângeri (fig ura 3)
care restric ționeaz ă urm ătoarele rela ții:
– rela țiile de tip AU (Asign ări Utilizator): la un moment dat un utilizator nu
poate de ține decât un singur rol, rela ție de 1:1 (similar RBAC);
– rela țiile de tip AR (Asign ări Roluri) care asigneaz ă un rol unei ma șini de
stare, rela ție de 1:1 (diferit fa ță de RBAC).
– Rela ții de tip AM (Asign ări Ma șini de stare), o ma șin ă de stare are asociate
mai multe permisiuni, rela ție de 1:n (diferit fa ță de RBAC);
– rela țiile sesiune – utilizator care sunt rela ții de tipul 1:1 (similar RBAC);
– rela țiile sesiune-rol care sunt rela ții de tipul 1:n (similar RBAC).
3.2.2 Ierarhiile de roluri
O ierarhie a rolurilor este din punct de vedere mat ematic o ordine par țial ă sau
total ă care define ște rela ții între roluri, unde rolurile senior dobândesc per misiunile
celor junior [FSG01]. Ierarhiile sunt structuri de roluri care reflect ă nivelul autori țătii
și al responsabilit ății.
Conceptul de ierarhie a rolurilor este introdus atâ t în modelul RBAC precum și
în unele dintre implement ările acestuia pentru îmbun ătățirea eficie ței și descrierea
structurilor organiza ționale.
Exist ă mai multe tipuri de ierarhii de roluri [SFK00]:
– ierarhii generale. În acest caz exist ă o ordine par țial ă între roluri care
serve ște drept ierarhie și include mo ștenirea multipl ă a permisiunilor; este
definit ă rela ția de membru a unui utilizator la un grup de roluri ;
– ierarhii limitate. In acest caz se introduc restric ții în cadrul ierarhiei
rolurilor. Cel mai adesea ierarhiile sunt limitate la structuri simple precum
arbori sau arbori inver și. Utilizatori Roluri Asign ări
utilizator
(AU)
Utilizator /
sesiuni Sesiune /
rol Asign ări roluri
(AR) Permisiuni
Sesiuni Obiecte Opera ții Ierarhia
rolurilor
Ma șini de
stare Asign ări ma șina
de stare (AM)
27
Figura 4 Exemple de ierarhii de roluri: a) arbore; b) arbore invers; c) latice
Justificarea cerin țelor de tranzitivitate, reflexivitate și ale propriet ăților de
asimetrie pentru ierarhiile limitate este discutata pe larg în literatura de specialitate
28 [FCK95], [SCH +96], [M98]. Oricum exist ă un num ăr mic de produse care suport ă
ierarhiile limitate. In figura 4 sunt exemplificate câteva tipuri de ierarhii.
Ierarhiile de roluri sunt în mod uzual incluse ca și componente cheie ale
modelelor RBAC [FCK95] si reprezinta structuri în c are fiecare rol reflect ă o pozi ție
organiza țional ă a autorității și responsabilit ății proprii.
Dup ă cum am mai amintit, ierarhiile de roluri definesc rela țiile de mo ștenire
între roluri. Mo ștenirea se refer ă la permisiuni astfel: dac ă rolul “r 1” mo ștene ște
drepturile rolului “r 2” toate drepturile lui “r 2” sunt și ale lui “r 1”.
Standardul RBAC NIST [FSG01], [FGL95] recunoa ște atât ierarhiile generale
cât și ierarhiile limitate de roluri. Ierarhiile general e includ conceptul de mo ștenire
multipl ă a permisiunilor.
Ierarhiile limitate impun restric ții, rezultând o structur ă mai simpl ă, de arbore
(vezi figura 3) în care un rol poate avea unul sau mai mul ți ascenden ți imedia ți dar
este restric ționat la un singur descendent. De notat c ă permisiunile sunt transmise de
jos în sus în cadrul unei ierarhii și, prin urmare, ierarhiile generale permit mo ștenirea
multipl ă iar ierarhiile limitate permit mo ștenirea simpl ă.
In exemplul considerat în figura 3, în ierarhia a), Inginer 1 moștenește
permisiunile de la Departamentul de Ingineri , la care se adaug ă permisiuni proprii
specifice. Un Inginer Produc ție 1 moșteneste permisiunile de la Inginer 1 ,
permisiunilor sale ad ăugându-li-se și unele specifice. Aceasta ierarhie este o ierarhie
de tip arbore și este conform defini ției o ierarhie limitat ă.
In figura 3, în ierarhia b), rolul de Director moștenește permisiuni de la mai
mult de un rol junior (de la Manager 1 și Manager 2 ), este o ierarhie de tip arbore
invers și conform defini ției este o ierarhie general ă.
Ierarhia din figura 3 c) este o ierarhie latice și este tot o ierarhie general ă
deoarece exist ă moștenire multipl ă.
Ierarhia SCAR-ACE este o ierarhie limitat ă de tip arbore (vezi figura 3 a)).
Rolurile în ierarhie sunt restric ționate la un singur descendent imediat și la un singur
ascendent imediat (fiecare rol senior are un singur rol junior și fiecare rol junior are
un singur rol senior).
Fiecare rol din cadrul ierarhiei de roluri are ata șat ă o ma șin ă de stare specific ă
rolului, accesul unui rol la permisiuni realizându- se doar prin intermediul ma șinii de
stare corespunz ătoare. Dintr-un rol junior (oricare ar fi starea de autorizare a acestuia)
se poate trece în oricare rol senior din cadrul ier arhiei de roluri doar prin autentificare.
Trecerea de la un rol senior la un rol junior din c adrul ierarhiei se realizeaz ă fără
autentificare.
3.2.3 Rela țiile statice
Rela țiile RBAC sunt rela ții de separare a îndatoririlor și impun constrângeri
asupra modelului. Rela țiile de separare a îndatoririlor sunt utilizate pen tru a evita
conflictul de interese în cadrul unei organiza ții (pentru a preveni un utilizator de a
exceda nivelul de autorizare corespunz ător pozi ției sale).
Ca și principiu de securitate, separarea îndatoririlor a fost recunoscut ă pentru
larga sa aplicabilitate în business, industrie și altele [BN89], [CW87]. Pentru a
minimiza posibilitatea erorilor intr-o organizatie, indivizilor cu atribute diferite sau
interese divergente li se asigneaz ă roluri și permisiuni diferite.
29 Standardul NIST RBAC permite atât rela ții statice cât și dinamice (vezi și
3.2.4).
Rela țiile statice se refer ă la separarea static ă a îndatoririlor și sunt utilizate
pentru evitarea conflictelor în autorizare. Un conf lict de interese într-un sistem bazat
pe roluri poate ap ărea ca rezultat al ob ținerii autoriz ării de c ătre un utilizator pentru
permisiuni asociate cu roluri conflictuale (de exem plu vânz ător și cump ărător al
aceluia și produs). O posibilitate de evitare a acestor conf licte de interese este prin
separarea static ă a îndatoririlor (SSD) [K97]. Un exemplu de SSD poa te fi o
constrângere care impune ca dou ă roluri s ă fie mutual exclusive; de exemplu dac ă un
rol necesit ă cheltuieli și altul le aprob ă, organiza ția poate s ă interzic ă atribuirea
ambelor roluri aceluia și utilizator.
Rela țiile SSD furnizeaz ă un mijloc pentru evitarea conflictelor de interese .
Constrângerile statice pot lua o varietate de forme . Un exemplu uzual este definirea
asign ărilor disjuncte relativ la un set de roluri [GI96], [K97]. [GGF98], [SZ83],
[AS00] [JT00] au identificat rela ții SSD pentru includerea constrângerilor asupra
utilizatorilor, opera țiilor și obiectelor precum și a diverselor combina ții între acestea.
Modelul SCAR-ACE con ține rela ții SSD și implementarea acestora are loc prin
utilizarea unei ma șini de stare pentru fiecare rol. Dac ă exist ă st ări prin care un
utilizator (prin intermediul unui rol) are acces la resurse, pentru realizarea rela țiilor
SSD ma șina de stare va încapsula doar acele st ări și tranzi ții care sunt permise rolului
în cauz ă.
3.2.4 Rela țiile dinamice
Rela țiile dinamice DSD, similar celor statice, limiteaz ă permisiunile
utilizatorilor. Rela țiile DSD difer ă de cele SSD prin contextul în care aceste limit ări
sunt impuse. Cerin țele DSD limiteaz ă drepturile prin plasarea constrângerilor asupra
rolurilor care pot fi activate în timpul unei sesiu ni utilizator (cu alte cuvinte, in mod
dinamic, la rulare).
Rela țiile DSD definesc constrângerile ca și o pereche:
RDSD = { Ua | a = (rk, n, ss), rk ∈ R, n ≥ 2, ss ∈ SS}
unde:
n: un num ăr natural mai mare sau egal cu 2 cu proprietatea c ă în nici o sesiune
ss din SS nu pot fi activate simultan n sau mai multe roluri rk din setul de roluri R.
Propriet ățile DSD furnizeaz ă o extensie pentru principiul privilegiilor minime
deoarece un utilizator are nivele diferite de permi siuni la momente diferite, în func ție
de sarcina efectuat ă. Aceasta caracteristica este întâlnita sub denumir ea de revocarea
temporar ă a încrederii [K97].
Relatiile SSD se refer ă la capacitatea de adresare a unui conflict de inte rese în
momentul în care se asigneaz ă un rol unui utilizator. DSD permite unui utilizato r s ă
fie autorizat pentru un rol care nu cauzeaz ă un conflict de interese când acesta se
activeaz ă independent, dar care produce conflict când este a ctivat simultan de mai
mul ți utilizatori.
30 Rela țiile DSD în modelul SCAR-ACE sunt realizate prin re stric ția impus ă la
asignarea rolurilor. Astfel nu pot fi activate simu ltan de diver și utilizatori anumite
roluri precum cel de administrator, recep ționer al unei cereri sau distribuitor al unui
produs. Pentru a realiza rela țiile DSD, modelul SCAR-ACE utilizeaz ă tot ma șini de
stare și anume: la un moment dat un utilizator face parte din una și numai una din
ma șinile de stare și anume cea care corespunde rolului s ău. Fiecare ma șin ă de stare
este gestionat ă de un manager care con ține și num ărul de utilizatori care acceseaz ă
simultan un rol. In cazul în care exist ă restric ții de cardinalitate, acestea sunt rezolvate
de c ătre managerul ma șinii de stare.
3.2.5 Extensiile
In afara componentelor amintite mai sus, exist ă și alte caracteristici specifice
anumitor modele, caracteristici denumite extensii a le modelului RBAC.
Delegarea
Delegarea permite unui utilizator s ă imputerniceasc ă al ți utilizatori cu o parte a
drepturilor sale. Motivarea vine din lumea real ă, unde exist ă utilizatori care necesit ă
să ac ționeze în favoarea altor utilizatori pentru accesar ea resurselor, în cazul în care,
de exemplu, se îmboln ăvesc. Exist ă o cercetare intens ă în acest domeniu din care
amintim [BS 100], [BS 200], [NC00], [ZAC01]. Anumi ți cercet ători consider ă
delegarea par țial ă în care doar privilegiile sunt delegate, sau când rolul delegat este cu
constrângeri. Diferite tipuri de delegare sunt desc rise în [BS 100].
No țiunea de delegare este strâns interconectat ă cu cea de revocare, care permite
utilizatorilor delega ți s ă revoce un anumit rol, sau permite rolurilor s ă fie revocate
utilizând constrângeri de timp. Arhitecturile care suport ă delegarea și revocarea difer ă
prin modul în care acestea au fost implementate.
Parametri
Anumite modele RBAC includ parametri pentru roluri și/sau privilegii. Rolurile
parametrizate pot fi rafinate în timpul activ ării prin setarea valorii parametrilor. De
notat c ă valoarea acestor parametri este fix ă si nu poate fi modificat ă ulterior.
Parametrii privilegiilor, similar parametrilor rolu rilor, primesc valori la crearea
instan ței; consecvent, parametrii seta ți ai unui privilegiu nu mai pot fi modifica ți.
Astfel de privilegii con țin informa ții despre obiectul accesat.
In timp ce parametrii introduc o modalitate de abst ractizare a rolurilor și
privilegiilor, ace știa pot crea probleme pentru ierarhiile de roluri. Daca parametrii
rolurilor trebuie seta ți intr-o ierarhie, aceasta putand reprezenta o prob lem ă dac ă
parametrii rolului p ărinte variaz ă semnificativ fa ță de cei ai rolului fiu. In astfel de
cazuri rela ția de moștenire trebuie s ă includ ă informa ții de setare a parametrilor.
Constrângerile devin, prin suportarea parametrilor, mai complexe [J99]. In mod
corespunz ător analiza rela țiilor statice devine mai dificil ă. De exemplu, parametrii
complic ă verific ările de cardinalitate deoarece doar identificatorii rolurilor nu mai
sunt suficienti pentru distingerea acestora, necesi tându-se memorarea unei cantit ăți
mai mari de informa ție de stare.
31 Dependen ța de context
Cerin țele pentru limbaje de specificare a controlului acc esului sunt în cre ștere.
Aceasta a determinat sa fie necesar ă considerarea contextului în care se realizeaz ă
deciziile de control al accesului [CLS +01]. Suportul pentru dependen ța de context
poate con ține de la evaluarea predicatelor temporale [BBF01] până la predicate
complexe care furnizeaz ă informații despre sistemul de operare [GMS94] sau poate
permite evaluarea predicatelor arbitrare [BMY02]. A ceast ă extensie a RBAC permite
restric ții suplimentare ad ăugate rolurilor, restric ții care pot fi temporale sau de acces a
bazelor de date.
Scalabilitatea
Scalabilitatea este un factor important în cadrul s istemelor de control al
accesului. Un sistem RBAC centralizat s-ar putea s ă nu respecte cerin țele unei
organiza ții mari dispersate geografic; astfel este esen țial ă considerarea sistemelor
distribuite.
Un sistem distribuit introduce multe provoc ări. Pentru a aduce suport
utilizatorilor care acceseaz ă resurse din diferite loca ții, majoritatea implement ărilor
lucreaz ă cu sesiuni. Aceasta complic ă verificarea constrângerilor: de exemplu este
mai dificil de a ob ține informa ții relativ la rolurile active ale unui utilizator. Aceste
sisteme trebuie, de asemenea, s ă fie pregatite s ă controleze eventualele e șecuri de
comunicare in re țea. Ca o consecin ță, politica trebuie extins ă pentru a permite
specifica ții de deteriorare a condi țiilor de rulare. Datorit ă acestor constrângeri exist ă
diferite extensii ale modelelor RBAC.
Politici obligatorii
Majoritatea modelelor RBAC sunt permisive, adic ă specific ă ceea ce poate un
subiect s ă fac ă. In contrast, politicile obliga ționale [LS97], care î și au originea în
cerin țele de management al aplicatiilor, specific ă ceea ce trebuie sau nu trebuie s ă
fac ă un subiect asupra unor obiecte.
Un exemplu de limbaj RBAC care suport ă obligativitatea este Ponder [LS97].
Obliga țiile lucreaz ă bine cu alte caracteristici RBAC, de exemplu cu ie rarhiile și
contextul. Limbajul propus de Schaad et al. [SM02] propune investigarea integr ării
obligativit ății cu extensiile RBAC care permit delegarea.
Politici negative
Permisiunile specificate în majoritatea modelelor R BAC sunt pozitive adic ă se
specific ă ce poate un utilizator s ă fac ă. In asemenea medii, politica implicit ă refuz ă
accesul dac ă acesta nu este permis explicit.
Pe de alta parte, permisiile negative sunt opusul c elor pozitive; acestea specific ă
ceea ce un utilizator nu poate s ă fac ă. Dac ă sunt specificate doar politicile negative,
controlul accesului va permite tot ceea ce nu este în mod explicit interzis.
Un model poate include atât politici pozitive cât și negative, un exemplu
reg ăsindu-se în [L98]. Utilizarea ambelor politici poat e duce îns ă la conflicte, anumite
ac țiuni putând fi atât permise cât și interzise în acelasi timp.
32 Roluri rela ționate cu pozi ția versus roluri rela ționate cu taskurile
Rolurile grupeaz ă atât privilegii cât și utilizatori. In func ție de abordare, rolurile
pot fi grupate în mai multe moduri. In [SBC +97] sunt descrise trei tipuri de entitati:
abilit ăți, grupuri, și roluri UP. Abilit ățile sunt roluri care pot avea doar privilegii ca și
membri, și nu pot grupa utilizatorii. Grupurile, pe de alta parte, colecteaz ă utilizatori
dar nu consider ă în mod implicit privilegiile de acordat. Rolurile UP au atât utilizatori
cât și privilegiile asociate acestora.
O alt ă clasificare a rolurilor este bazat ă pe coresponden ța din lumea real ă a
acestora [NS02]. Conform acestei clasific ări un rol poate fi func țional sau
organiza țional. Un rol func țional grupeaz ă privilegii corespunzatoare unei func ții. De
exemplu rolul de database_user este un rol func țional. Un avantaj al rolurilor
func ționale este c ă au o durabilitate mai mare în compara ție cu rolurile
organiza ționale. Un rol organiza țional reflect ă pozi ția unei persoane în cadrul ierarhiei
de roluri din companie. De exemplu, un astfel de ro l este cel de manager . RBAC
suport ă rolurile organiza ționale prin ierarhii.
Când RBAC nu este suficient
Toate aceste extensii pot crea senza ția c ă RBAC este un model foarte expresiv,
dar exist ă cazuri când este destul de dificil de a exprima lu mea real ă cu ajutorul
rolurilor și a modului de activare a acestora. Un exemplu poat e fi o echip ă care are un
scop și în care membrii echipei colaboreaz ă. In astfel de cazuri se determin ă alte tipuri
de control al accesului precum controlul accesului bazat pe echipe [T97] sau pe
taskuri [TS97].
Un alt scenariu în care RBAC nu este suficient este în cazul workflow-urilor.
Pentru a lucra cu workflow-uri sistemul RBAC necesi t ă considerarea informa țiilor
externe de exemplu stadiul actual al proceselor de business, cum ar fi extensiile
propuse în [BFA97] și [HA99].
3.3 Modele conceptuale
In aceasta sectiune analizez modelele conceptuale R BAC si, prin paralelism,
modelele conceptuale SCAR-ACE.
3.3.1 Modele RBAC conceptuale
Pentru a analiza diferite versiuni RBAC s-a definit o familie de patru modele
conceptuale (figura 5) [SCH +96]. RBAC 0 este modelul de baz ă și este cerin ța minim ă
pentru un sistem de control al accesului bazat pe r oluri. Modelele avansate RBAC 1 și
RBAC 2 includ modelul RBAC 0. RBAC 1 introduce ierarhiile de roluri (situa ții în care
rolurile mo ștenesc permisiuni de la alte roluri) în timp ce RBA C 2 adaug ă constrângeri
(care impun restric ții între componente). Modelul consolidat RBAC 3 include modelele
RBAC 1 și RBAC 2 și, prin tranzitivitate, RBAC 0.
33
Figura 5. Modele RBAC conceptuale
In abord ările RBAC se presupune c ă, pentru managementul sistemului, exist ă
un singur administrator autorizat s ă configureze diversele set ări și rela ții între
componente. Aceasta nu elimin ă existen ța unui model de management și configurare
mai sofisticat.
Conceptul RBAC suport ă urm ătoarele principii de securitate:
• Privilegiul minim : unui rol ii sunt asignate doar acele permisiuni
necesare pentru îndeplinirea sarcinilor;
• Separarea îndatoririlor : pentru îndeplinirea unei sarcini este necesar ă,
în unele cazuri, invocarea cumulat ă a rolurilor mutual exclusive
(exemplu: necesitatea particip ării atât a func ționarului cât și a
managerului unui cont în emiterea unui cec);
• Abstractizarea datelor : în locul permisiunilor tipice de citire / scriere
dintr-o / intr-o baz ă de date, se pot stabili permisiuni abstracte precu m
cele de credit și debit pentru un cont.
Emit dou ă observa ții relativ la aceste principii:
1. RBAC nu impune modul de aplicare a acestor principi i. Teoretic, un
administrator de sistem poate configura RBAC astfel încât acesta s ă
violeze aceste principii.
2. Nivelul de abstractizare a datelor este determinat de implementare.
3.3.2 Modele SCAR-ACE conceptuale
Modelul SCAR-ACE se refer ă la un RBAC 3 și, pentru realizarea SSD și DSD,
impune constrângeri. Astfel pentru realizarea SSD s e restric ționează realizarea static ă
a ma șinii de stare pentru fiecare rol iar pentru DSD se impun constrângeri de
simultaneitate în asignarea rolurilor și restric ții relativ la sesiuni multiple utilizator.
Deoarece RBAC 3 include toate modelele RBAC inferioare, prin paral elism,
modelul SCAR-ACE este compus din SCAR-ACE 0, SCAR-ACE 1, SCAR-ACE 2 si
SCAR-ACE 3. In continuare m ă voi referi la toate nivelele conceptuale ale model ului
SCAR-ACE și la specificul acestora [OG 207].
3.3.3 Modelul de baz ă SCAR-ACE 0
Modelul de baz ă SCAR-ACE 0 const ă din urm ătoarele entit ăți: utilizatori (U),
roluri (R), masini de stare (M), permisiuni (P) și sesiuni (S).
In figura 4 sunt ilustrate entitatile mai sus amint ite si urmatoarele relatii:
asign ările utilizator (AU) , asignarile rolurilor (AR) și asignarea ma șinilor de stare RBAC 1 RBAC 3
RBAC 2
RBAC 0
34 (AM) ; asignarea utilizatori – roluri este o rela ție de tipul n:m în sensul c ă un utilizator
poate de ține mai multe roluri intr-o sesiune și un rol poate fi asignat mai multor
utilizatori. Rela ția roluri-permisiuni este o rela ție de n:m, un rol având asignate mai
multe permisiuni și o permisiune putând fi asignat ă mai multor roluri. Aceast ă rela ție
de roluri – permisiuni este implementat ă prin intermediul ma șinilor de stare. A șadar,
prin tranzitivitate, un utilizator poate exercita p ermisiuni. Pozitia rolului ca și
intermediar în aceste rela ții permite unui utilizator s ă exercite permisiuni si furnizeaz ă
un control m ărit pentru controlul accesului.
Utilizatorii stabilesc sesiuni în timpul c ărora își activeaz ă un subset al rolurilor
pe care le de țin. Permisiunile disponibile unui utilizator reprez int ă reuniunea
permisiunilor tuturor rolurilor activate în cadrul acelei sesiuni. In SCAR-ACE 0 fiecare
sesiune este asociat ă unui singur utilizator, aceast ă asociere r ămânând constant ă pe
întreaga durat ă a sesiunii.
Modelul de baza SCAR-ACE 0 suportă principiul minimului privilegiu: un
utilizator care de ține câteva roluri pe durata unei sesiuni poate invo ca consecutiv orice
subset al acestora pentru a permite realizarea unei sarcini. Astfel, un utilizator care
poate de ține un rol autorizat poate s ă păstreze acest rol deactivat și s ă îl activeze
explicit doar atunci când are nevoie de acesta.
3.3.4 Definirea formal ă a modelului SCAR-ACE 0
In rela ție cu RBAC 0 am introdus definirea formal ă a modelului SCAR-ACE 0
care are urm ătoarele componente:
– U, R, P, S și M (multimile de utilizatori, roluri, permisiuni, ses iuni și
respectiv ma șini de stare);
– Rela ția utilizator – roluri: R UR ⊆ U x R , o rela ție de asignare n:m pentru
utilizatori-roluri
RUR = {ur | ur = (u, r), ( ∀u ∈ U, ∃ r ∈ R) ∧ ( ∀r ∈ R, ∃ u ∈ U) };
– Rela ția sesiune – utilizator : RSU ⊆ S → U , o rela ție 1:1 care mapeaz ă fiecare
sesiune unui singur utilizator (constant pentru tim pul de via ță al sesiunii)
RSU = {su | su = (s, u), ( ∀s ∈ S, ∃ ! u ∈ U);
– Rela ția rol – ma șina de stare: R RM ⊆ R → M o rela ție 1:1 care mapeaz ă
fiecare rol la o singur ă ma șin ă de stare
RRM = {rm | rm = (r, m), ( ∀r ∈ R, ∃ ! m ∈ M);
– Rela ția ma șina de stare – permisiuni : RMP ⊆ M → P, o rela ție 1:n care
mapează fiecare ma șina de stare la un set de permisiuni
RMP = {mp | mp = (m, p), ( ∀m ∈ M, ∃ p ∈ P).
Fiec ărui rol este obligatoriu a i se asigna o ma șin ă de stare și fiec ărui utilizator
cel pu țin un rol. Modelul SCAR-ACE impune aceste condi ții.
Permisiunile de modificare a seturilor R și M și a rela țiilor RRM și RMP sunt
denumite permisiuni admistrative și fac parte din rolul de administrator .
Sesiunile sunt sub controlul individual al utilizat orilor. Din punct de vedere al
modelului, un utilizator poate crea doar o sesiune. Rolurile active într-o sesiune pot fi
modificate la dispozi ția utilizatorului prin autentificare. Sesiunea ia s fâr șit fie la
ini țiativa utilizatorului fie dac ă aceasta activeaz ă prea mult. Strict vorbind, aceasta
este o constrângere și apar ține RBAC 2.
35 Anumi ți autori [J93] consider ă îndatoririle, în plus fa ță de permisiuni, ca fiind
un atribut al rolurilor. O îndatorire este obligati vitatea unui utilizator de a realiza una
sau mai multe sarcini care sunt în general esen țiale pentru func ționarea unei
implement ări. Modelul SCAR-ACE consider ă îndatoririle un concept avansat care nu
se refer ă la SCAR-ACE 0.
3.3.5 Ierarhiile de roluri și abordarea acestora în SCAR-ACE 1
Modelul SCAR-ACE 1 introduce ierarhiile de roluri. Ierarhiile de rolu ri sunt
discutate în literatur ă în mod invariabil împreun ă cu rolurile [FK92], [HD95],
[NO94], [SM00].
Mo ștenirea permisiunilor într-o ierarhie este tranziti v ă și, într-o ierarhie, pot
exista mo șteniri multiple.
Din punct de vedere matematic, aceste ierarhii sunt ordon ări par țiale. O ordine
par țial ă este o rela ție reflexiv ă, tranzitiv ă și asimetric ă. Mo ștenirea este reflexiv ă
deoarece un rol î și mo ștene ște propriile permisiuni; tranzitivitatea este o cer in ță în
acest context; regulile de asimetrie elimin ă rolurile care mo ștenesc toate permisiunile
unul de la cel ălalt și ar fi astfel redundante.
Modelul SCAR-ACE 1 este definit pentru ierarhia ilustrat ă în figura 3.a.
3.3.6 Definirea formal ă a modelului SCAR-ACE 1
In continuare introduc defini ția formal ă a modelului SCAR-ACE 1:
– U, R, P, S, M acelea și cu cele din SCAR-ACE 0;
– IR ⊆ R x R , reprezintă o ordonare par țial ă pe R denumită ierarhie de roluri
sau rela ție de dominan ță a rolului, denotat ă ≥;
– Rela țiile sunt acelea și cu cele din SCAR-ACE 0.
Uneori este util ă limitarea mo ștenirii. Spre exemplu, în figura 3.c. rolul de
manager de proiect este senior rolului de inginer p roduc ție și celui de inginer pentru
asigurarea calit ății. Rolul de inginer de asigurare a calit ății ar trebui să poată avea
anumite permisiuni doar ale sale și s ă previn ă mo ștenirea acestora de c ătre rolul
managerului de proiect. Aceste permisiuni proprii r olului inginerului pentru
asigurarea calit ătii pot forma un rol aparte numit rol privat [J98]. Rolurile private se
ob țin în cadrul anumitor sisteme prin blocarea mo ștenirii unor permisiuni dar aceast ă
tehnic ă previne ierarhia de a ilustra cu acurate țe distribu ția permisiunilor.
3.3.7 Modelul constrângerilor în SCAR-ACE 2
Cel de-al treilea model – SCAR-ACE 2 – introduce constrângeri. Cu toate c ă
aceste modele sunt denumite SCAR-ACE 1 și SCAR-ACE 2, nu există un progres real
implicat. In aceste modele se introduc fie ierarhii le fie constrângerile dar nu ambele.
Constrângerile reprezint ă un aspect important al oricarui model de control a l
accesului. Un exemplu de constrângeri este cel al r olurilor mutual exclusive. In
general, unui utilizator nu i se permite apartenen ța la dou ă roluri mutual exclusive
deoarece aceasta ar putea crea posibilitatea comite rii fraudelor. Acest principiu se
nume ște separarea îndatoririlor .
36 SCAR-ACE 2 este nemodificat fa ță de SCAR-ACE 0 cu excep ția faptului c ă sunt
necesare constrângeri pentru a determina nivelul de acceptare al diferitelor
componente SCAR-ACE 0.
Modelul SCAR-ACE 2 realizează dou ă seturi de constrângeri (vezi și sec țiunea
4.4) și anume constrângeri statice și constrângeri dinamice.
3.3.8 Definirea formal ă a modelului SCAR-ACE 2
Componentele modelului formal SCAR-ACE 2 sunt:
– U, R, P, M și S (multimile de utilizatori, roluri, permisiuni, mas ini de stare și
respectiv sesiuni);
– P ∈ SP , permisiunile P sunt parte a unui set SP (se impun constrângeri
asupra permisiunilor și se specific ă permisiunile acceptate și nu cele care
sunt respinse);
– Ri ≠ Rj , ∀Ri, Rj ∈ R , definesc rolurile mutual exclusive;
– ma șina de stare : M ↔ R, o func ție biunivoc ă care mapează fiecare ma șin ă
de stare unui rol și fiecare rol unei ma șini de stare. Prin intermediul acesteia
se realizează constrângerile relativ la roluri.
Implement ările RBAC în general aplic ă constrângeri simple care pot fi u șor și
eficient verificate sau for țate. In RBAC constrângerile simple pot avea diferit e forme.
Deoarece majoritatea constrângerilor aplicate rela ției de asignare a utilizatorilor la
roluri au și partea care se aplic ă rela ției de asignare a permisiunilor, se vor discuta în
paralel constrângerile pe aceste dou ă componente.
Cea mai uzual ă constrângere RBAC 2 este cea a rolurilor mutual exclusive. Un
utilizator poate fi asignat cel mult unui rol dintr -un set mutual exclusiv (în plus fa ță de
alte posibile roluri). Aceast ă constrângere realizeaz ă separarea îndatoririlor,
constrângere care este apoi asigurat ă prin asignarea permisiunilor.
Constrângerea dual ă asupra asign ării permisiunilor poate furniza asigur ări
adi ționale în separarea îndatoririlor (acesta este îns ă rareori men ționată în literatur ă).
Această constrângere dual ă impune în SCAR-ACE 2 ca o permisiune s ă fie asignată
cel mult unui rol dintr-un set mutual exclusiv. De exemplu, consider ăm dou ă roluri
mutual exclusive, cump ărător și vânz ător pentru acela și produs. Exclusivitatea
mutual ă în termenii rela ției RUR și RSU specifică faptul c ă un utilizator nu poate
apar ține ambelor roluri pentru acela și produs.
Mutual exclusivitatea în termenii rela țiilor RRM și RMP mai specifică faptul c ă
aceea și permisiune – încasarea cecurilor, de exemplu – nu poate fi asignat ă ambelor
roluri prin intermediul ma șinilor de stare specifice. In mod normal aceast ă permisiune
este asignată vânz ătorului. In general ar putea s ă nu conteze care dintre dou ă roluri A
sau B prime ște autorizarea semn ării unui anumit cec, dar conteaz ă ca doar unul dintre
aceste roluri s ă primească această permisiune și nu ambele.
In RBAC este introdus și conceptul de roluri prerechizite care este bazat pe
competen ță și coresponden ță (modalitatea prin care unui utilizator îi poate fi asignat
rolul B doar dac ă avea deja asignat rolul A).
37 SCAR-ACE 2 accepta rolurile prerechizite in modul urmator: ac cesul la rolul de
cump ărător (de exemplu) se poate realiza de catre un util izator dac ă ini țial a avut un
rol junior cu prioritate minim ă. Cu alte cuvinte, un utilizator nu poate accede la un rol
autorizat decât printr-un proces de autentificare.
O altă constrângere o reprezinta num ărul maxim de utilizatori ai unui rol.
Numai o persoan ă poate fi administrator, sau receptioner al unei ce reri; de asemenea
num ărul de roluri c ăruia îi poate apar ține un utilizator poate fi limitat. Acestea
reprezintă constrângeri de cardinalitate care pot fi aplicate în mod corespunz ător și
asign ării permisiunilor pentru a se controla distribuirea acestora. Pe de alt ă parte,
constrângerile de cardinalitate minim ă pot fi dificil de implementat. De exemplu, dac ă
un rol necesit ă un num ăr minim de membri, este dificil pentru sistem s ă cunoască
modul de r ăspuns corespunz ător în cazul în care unul dintre membri dispare.
Constrângerea dual ă asupra asign ării permisiunilor la roluri se aplic ă prin
intermediul rela țiilor R RM și R MP . Constrângerea dual ă impune ca permisiunea p s ă
poat ă fi asignată unui rol doar dac ă acest rol posed ă permisiunea q. De exemplu,
permisiunea de a citi un fi șier necesit ă permisiunea de a citi directorul în care acesta
rezid ă. Asignarea doar a primei permisiuni f ără cea asupra directorului ar fi
incomplet ă.
O ierarhie de roluri poate fi considerat ă o constrângere. Intr-o anumit ă m ăsur ă,
SCAR-ACE 1 este redundant și subsumat lui SCAR-ACE 2. Oricum, existen ța unei
ierarhii de roluri trebuie recunoscut ă ca atare.
In SCAR-ACE 2 constrângerile de asignare a utilizatorilor sunt e fective doar
dac ă este men ținută o disciplin ă în asignarea identificatorilor utilizator (ID). D acă
aceluia și individ i se asigneaz ă doi sau mai multi identificatori, separarea utiliz atorilor
și cardinalitatea acestora determin ă conflicte. Astfel, este strict necesar ă o
coresponden ță de 1:1 între identificator și utilizator pe intreaga durat ă a unei sesiuni.
In SCAR-ACE 2 un utilizator poate avea mai multe roluri pe durat a unei sesiuni
dar acestea nu pot fi mutual exclusive și nu pot fi active în acela și timp. Alt ă
constrângere limiteaz ă la 1 num ărul sesiunilor unui utilizator care ar putea fi act ive în
acela și timp.
Relativ la permisiuni, dac ă aceea și opera ție apar ține la dou ă permisiuni diferite,
modelul SCAR-ACE 2 nu poate for ța efectiv cardinalitatea și separarea
constrângerilor.
3.3.9 Modelul SCAR-ACE 3
SCAR-ACE 3 este caracterizat de ierarhii și constrângeri și combină modelele
SCAR-ACE 1 și SCAR-ACE 2.
Constrângeri asupra ierarhiilor de roluri. Constrângerile se pot aplica asupra
ierarhiei de roluri. De exemplu aplicarea unei ordi ni par țiale în cadrul ierarhiei de
roluri este o constrângere. Constrângerile pot limi ta num ărul rolurilor junior sau
senior pe care le poate avea un rol dat. Dou ă sau mai multe roluri pot fi, de asemenea,
constrânse s ă nu aib ă un rol senior sau junior comun. Asemenea constrâng eri sunt
utile când autorizarea de a modifica ierarhia de ro luri este descentralizat ă și
38 administratorul de sistem dore ște restric ționarea modului în care se realizeaz ă aceste
modific ări ale ierarhiei.
Interac țiuni. Intre ierarhii și constrângeri intervin interac țiuni. De exemplu
cump ărătorul și vânz ătorul au roluri mutual exclusive relativ la acela și produs.
Supervizorul stocului de produse violeaz ă această constrângere mutual exclusiv ă
deoarece are o parte a permisiuniunilor de la cump ărător și o parte de la vânz ător.
Modelul trebuie a șadar să poat ă implementa aceasta violare a constrângerilor.
Constrângeri de cardinalitate. Să presupunem c ă un utilizator poate fi asignat
unui singur rol și aceast ă constrângere s-ar aplica unui rol dintr-o ierarhie de roluri (de
exemplu asignarea rolului de inginer de test unui s ingur utilizator – vezi figura 6).
Intrebarea este: se aplic ă constrângeri de cardinalitate numai unui rol sau și
mo ștenitorilor acestora? In exemplul din figura 6 acea sta ar determina ca și
cardinalitatea membrilor în proiect s ă fie egala tot cu 1 ceea ce este eronat. R ăspunsul
la întrebarea anterioar ă determin ă constrângerile de cardinalitate s ă se aplice punctual
asupra fiec ărui rol dintr-o ierarhie deci constrângerile de car dinalitate nu reprezint ă o
caracteristic ă care se moștenește.
Figura 6. Exemplu de ierarhie de roluri
Modelul SCAR-ACE 3 accept ă atât o ierarhie limitat ă de roluri (vezi figura 7)
cât și constrângeri asupra rolurilor, permisiunilor (pri n ma șina de stare) și sesiunilor
(constrângeri de timp).
3.4 Analiza constrângerilor
Constrângerile autoriz ării bazate pe roluri se refer ă la asignarea rolurilor și a
permisiunilor. Principala caracteristic ă a modelului este aceea c ă permite delegarea
autorit ății prin ac țiuni administrative descentralizate. Un exemplu est e cel în care
două roluri r1 și r2 sunt declarate ca și mutual exclusive. O constrângere valid ă este
cea prin care unui utilizator nu îi pot fi asignate cele dou ă roluri exclusive în cadrul
aceleia și sesiuni în anumite condi ții. Astfel, presupunând c ă utilizatorul u1 are rolul
r1 , asignarea rolului r2 aceluia și utilizator u1 în cadrul aceleia și sesiuni ar determina
un conflict. Supervizor proiect
Inginer testare
Membru în proiect Programator
39 3.4.1 Prerechizite
Primul tip de constrângeri specific ă un set de prerechizite pe care un utilizator
trebuie s ă le satisfac ă pentru a de ține un anumit rol. O astfel de prerechizit ă poate fi
cea prin care unui utilizator i se cere s ă de țin ă un anumit rol înainte de a de ține un
altul (de exemplu: pentru a de ține rolul de vânz ător un utilizator trebuie s ă fi de ținut
anterior rolul de vizitator).
O alt ă prerechizit ă poate include evalu ări complexe de predicate, precum cele
care consider ă timpul. Au fost doar câteva încerc ări de formalizare a limbajelor care
să exprime tipuri particulare de constrângeri. O astf el de cercetare a fost realizat ă de
Bertino, Bonatti și Ferrari care s-au ocupat de constrângeri temporal e [BBF00].
3.4.2 Separarea îndatoririlor
Un alt tip de constrângere luat în considerare este cel de separare a îndatoririlor
SoD. Este considerat ă una dintre cele mai importante constrângeri și este adesea
motivarea principal ă în abordarea controlului accesului bazat pe roluri . SoD este o
tehnic ă prin care se reduc fraudele prin intermediul repar tiz ării responsabilit ății și
autorit ății pentru realizarea unei opera ții, între anumi ți utilizatori. Un exemplu uzual
este preg ătirea și aprobarea unui ordin de cump ărare. Astfel, ordinul trebuie s ă fie
ini țiat și aprobat de c ătre diferite persoane, frauda în acest caz implicân d conspira ția a
dou ă persoane, pu țin probabil a se întâmpla și ușor de descoperit. In [SZ83] se descriu
câteva tipuri de SoD:
– separarea static ă a îndatoririlor -SSD-, cunoscut ă ca și separarea puternic ă
a îndatoririlor, prin care se ob ține separarea îndatoririlor prin specificarea
de politici într-o manier ă care s ă nu permit ă nici unui utilizator s ă de țin ă
roluri care sunt conflictuale;
– separarea dinamic ă a îndatoririlor -DSD-, cunoscut ă ca și excluderea
slab ă, permite utilizatorilor s ă acceseze roluri conflictuale dar într-un timp
controlat și limitat. Pe baza controlului efectuat se deosebes c urm ătoarele
tipuri de excluziune slab ă:
/square4 separare dinamic ă simpl ă a îndatoririlor – împiedic ă utilizatorii în a
de ține roluri conflictuale în acela și timp;
/square4 separarea orientat ă pe obiect a îndatoririlor – permite utilizatorilor s ă
de țin ă roluri conflictuale, dar privilegiile conflictuale nu pot fi
exercitate asupra aceluia și obiect;
/square4 separarea opera țional ă a îndatoririlor – permite activarea rolurilor
conflictuale atâta timp cât nu con țin privilegii ale unei anumite
opera ții;
/square4 separarea bazat ă pe istoric a îndatoririlor – împiedic ă utilizatorul de a
efectua toate ac țiunile ata șate unei opera ții.
In [GGF98] sunt formalizate tipurile de separ ări ale îndatoririlor men ționate mai
sus. In [AS00] acestea sunt extinse prin furnizarea limbajului RSL99 pentru
descrierea tipurilor de separ ări ale îndatoririlor. In [K97] se furnizeaz ă un model
formal pentru exprimarea separ ării îndatoririlor dintr-o singur ă sesiune. Separ ări
adi ționale ale îndatoririlor precum Zidul Chinezesc se g ăsesc în [JSS97].
40 3.4.3 Cardinalitate
Constrângerile de cardinalitate limiteaz ă num ărul de sesiuni posibil a fi de ținute
de c ătre un utilizator sau num ărul de utilizatori activi în cadrul unui rol în ace la și
timp. De exemplu, cardinalitatea poate exprima o po litic ă prin care se stabile ște c ă în
sistem exist ă un singur administrator activ la un anumit moment dat. Cardinalitatea
este parte a constrângerilor de control a activ ărilor. Aceste constrângeri trebuie s ă fie
evaluate în momentul rul ării.
3.4.4 Constrângerile modelului
Modelul SCAR-ACE impune constrângeri de tipul prere chizite și separari ale
indatoririlor statice și dinamice.
Ca și prerechizite sunt acele constrângeri care impun o rdinea rolurilor in cadrul
ierarhiei de roluri, un utilizator neputând accede la roluri situate mai jos în ierarhie
far ă a parcurge rolurile anterioare care au responsabil itate și autoritate mai slab ă.
Din punct de vedere al sepaparilor indatoririlor st atice este controlat ă secven ța
de opera ții necesare satisfacerii unei cereri prin definirea tranzi țiilor posibile dintr-o
stare. Separarea dinamica a indatoririlor implica f aptul ca un utilizator poate s ă de țin ă
roluri mutual exclusive în dou ă sesiuni diferite dar nu pentru aceea și resursa.
In contextul SCAR-ACE rolurile sunt utilizate pentr u a modela diferite pozi ții și
scopuri în cadrul unei aplicatii de comer ț electronic. Un rol poate reprezenta
competen țe concrete precum cele ale unui vizitator, vânz ător sau cump ărător,
administrator de sistem, recep ționer sau distribuitor de bunuri. Rolurile pot refl ecta
asignarea unor îndatoriri și fiecare rol încapsuleaz ă autoritatea și responsabilitatea
specific ă, adic ă vizitatorul are autoritate și responsabilitate slab ă și limitat ă,
vânz ătorul poate insera articole în catalogul de produse iar cump ărătorul se poate
înregistra pentru a le achizi ționa.
Rolurile sunt organizate ierarhic iar în cadrul ace stei ierarhii este implementat ă
și rela ția de mo ștenire conform s ăge ților, respectiv rolurile de cump ărător și vânz ător
mo ștenesc permisiunile acordate rolului de vizitator ( vezi figura 7).
Rolul administrativ are permisiunea de a modifica s etul de roluri sau permisiuni,
sau de a modifica ma șinile de stare.
Utilizatorii pot accesa diferitele roluri existente (mai pu țin cel de administrator).
Acestor roluri le sunt ata șate, prin intermediul ma șinilor de stare, permisiunile
necesare efectu ării anumitor opera ții. RBAC nu solu ționeaz ă toate problemele legate
de controlul accesului. Sunt necesare metode mai so fisticate care s ă țin ă cont de
secven țele de control a opera țiilor. De exemplu, când o achizi ție necesit ă diver și pa și
înaintea emiterii ordinului de cump ărare, RBAC nu poate controla în mod direct
aceast ă secven ță de evenimente.
41
Figura 7. Ierarhia de roluri SCAR-ACE
Modelul SCAR-ACE emite creden țiale alc ătuite din mai multe atribute pentru
identificarea unei cereri. Secven țele posibile de opera ții care constituie permisiunile
unui rol sunt grupate în ma șini de stare a permisiunilor / rol. Introducerea ma șinilor de
stare in SCAR-ACE reprezint ă o extensie adus ă constrângerilor care sunt descrise
într-un model RBAC 3.
Entit ățile cu care opereaz ă SCAR-ACE sunt cele definite în figura 4. Resursele
la care se solicit ă accesul sunt metode ale obiectelor și date din baza de date. Atunci
când un utilizator dore ște să acceseze o resurs ă el emite o cerere. Când se prime ște
cererea de catre aplicatie, se identific ă emi ță torul acesteia și, dac ă acesta are
permisiunea de a accesa resursa cerut ă, prime ște acceptul. Mecanismul îns ă este
complex deoarece ia în considerare ma șina de stare și restric țiile impuse de aceasta.
Astfel, pentru a accesa o resurs ă oferit ă de sistem, utilizatorul parcurge un set de
opera ții permise de st ările ma șinii de stare. La un moment dat fiecare utilizator este
într-o stare bine definit ă de unde are posibilitatea de a emite cereri pentru anumite
resurse. Fiecare cerere poate fi emis ă prin lansarea unui eveniment care va interoga
sistemul la modul: “Pot rezolva din rolul r cererea pentru resursa x, din starea y, prin
lansarea evenimentului z în prezen ța parametrilor v?” Sistemul verific ă combina ția
emis ă și poate r ăspunde fie prin acordarea permisiunii de acces la r esurs ă în caz de
succes, fie printr-un mesaj de eroare în caz de e șec. Dup ă ce se realizeaz ă accesul la
resurs ă, are loc o tranzi ție de la starea din care s-a emis cererea la starea urm ătoare.
Identificarea emi ță torului cererii este realizat ă prin interpretarea unui creden țial.
Modelul crează, memorează și gestionează informa țiile de autorizare în mod dinamic
și distribuit. Proprietatea necesar ă unui utilizator pentru autorizare este deci un
creden țial care con ține mai mult decât o identificare a utilizatorului. In momentul în
care un utilizator emite o cerere pentru o resurs ă această cerere poartă ștampila
tranzitiilor prin care se realizeaz ă accesul.
Fiecare utilizator poate accesa resurse prin interm ediul ma șinii de stare, având
anumite permisiuni, și toate acestea pe durata unei sesiuni. Sesiunile i mpun
constrângeri asupra modelului și anume: dac ă un utilizator nu emite o cerere nou ă
într-un anumit interval de timp, sesiunea acestuia ia sfâr șit automat. Timpul este o
variabila parametrizabil ă care poate fi modificat ă dinamic.
Una dintre cerin țele RBAC este aceea ca utilizatorilor s ă le fie permis ă
exercitarea rolurilor multiple. Astfel, modelul SCA R-ACE are ma șini de stare și nu
re țele Petri tocmai pentru a permite acest mecanism.
Pentru realizarea autoriz ării într-un sistem distribuit, este necesar un mode l în
care deciziile de control al accesului s ă se bazeze pe atribute de identificare. Astfel,
modelul SCAR-ACE are urm ătoarele caracteristici:
a) Atributele specifice st ărilor ma șinii de stare sunt distribuite: fiecare stare
are atribute specifice care o identific ă iar aceste atribute sunt atât pe server
cât și pe client. Trecerea de la o stare la o alt ă stare se realizeaz ă pe baza Vizitator
Vânz ător Cump ărăto r
42 unor atribute proprii fiec ărei st ări. SCAR-ACE asociaz ă unei st ări o
interfa ță utilizator grafic ă sau anumite componente ale acesteia. In acest
caz o stare este caracterizat ă de elemente active și pasive con ținute de
către interfa ța care o define ște;
b) Caracteristica de delegare a autorit ății atributelor: o stare î și deleag ă
autoritatea unei alte st ări în sensul că o stare are încredere în “judecata”
altei st ări pe baza atributelor acesteia. Controlul accesulu i implic ă
impunerea unor secven țe logice autorizate pentru fiecare rol în parte
(controlate prin ma șina de stare) de la care un utilizator nu se poate abate
si nu poate for ța un alt traseu al starilor în afara celor predefin ite. Această
secven ță are loc pe baza încrederii trecerii de la o stare la alta pe baza
unuia sau a mai multor atribute care formeaz ă creden țiale;
c) Caracteristica de conjunc ție a atributelor: o cerere utilizeaz ă conjunc ția
între câteva atribute pentru a trece dintr-o stare în alta. In general o stare
este asociat ă câtorva elemente (active și / sau pasive) dintr-o pagin ă a
interfe ței utilizator. Toate aceste elemente sunt considera te atribute ale
st ării respective;
d) Atributele au valori: cel pu țin unul dintre atributele caracteristice unei
st ări are ata șat ă o valoare. De exemplu acesta poate fi un câmp (exe mplu
produsul de achizi ționat) care are o valoare selectabil ă dintr-o list ă dat ă.
Toate valorile atributelor unei st ări formeaz ă parametrii de apel în cererea
de accesare a unei resurse.
3.5 Privilegiile
Includerea privilegiilor în cadrul designului și a implement ării este adesea, în
accep țiunea RBAC, delegat ă bazei de date [DDT +04].
Includerea privilegiilor în cadrul SCAR-ACE se refe r ă la definirea nivelelor și a
politicilor de acordare a privilegiilor. Politicile de acordar e a privilegiilor se refer ă la
resursele de protejat, utilizatorii și rolurile sistemului precum și permisiunile acordate.
Nivelele de acordare a privilegiilor se refer ă la autorizare:
• autentificarea – pentru verificarea utilizatorilor și limitarea ac țiunilor lor
la privilegiile acordate acestora;
• controlul accesului – necesar acord ării sau revoc ării de privilegii
utilizatorilor.
Autentificarea si controlul accesului sunt cerin țele minimale de acordare a
privilegiilor și implic ă introducerea politicii de securitate în primele et ape ale ciclului
de via ță al aplica ției.
Modelul SCAR-ACE se bazeaza pe o politic ă restrictiv ă care s ă nu permită
accesul decât într-o anumit ă secven ță impus ă cu desemnarea clar ă a punctului de start
(de obicei pagina “Home”). Cu toate c ă există roluri cu grade diferite de securitate,
modelul impune controlul accesului pentru toate gru purile de utilizatori inclusiv
pentru cele cu prioritate minim ă.
Autentificarea se realizeaz ă prin metoda devenit ă clasic ă și anume
identificatorul utilizatorului și parola definesc fiecare utilizator autorizat al aplica ției
de comer ț electronic.
Autorizarea impune grupuri de privilegii pentru div erse tipuri de utilizatori.
Asigurarea acord ării privilegiilor impune utilizarea creden țialelor în controlul
secven ței de opera ții. Fiecare creden țial încapsuleaz ă mai multe informa ții care
43 identifică atât utilizatorul (identificator unic utilizator), rolul utilizatorului în sistem,
opera ția curentă cât și cererea pentru opera ția urm ătoare. Toate acestea pot determina
fie ob ținerea accesului la opera ția și resursele cerute în caz de succes fie un r ăspuns de
eroare dac ă accesul nu este permis.
3.5.1 Specificarea nivelelor de acordare a privileg iilor
Una dintre uneltele importante în proiectarea softw are este UML (Unified
Modeling Language) care este un limbaj de specifica re, vizualizare, construire și
documentare de artefacte software. UML unific ă mai multe abord ări [B+91], [J+92],
[R+91] și altele, într-un standard astfel încât s ă încapsuleze caracteristicile modelelor
constituente.
In UML există diferite tipuri de diagrame (nou ă tipuri de diagrame) dintre care
amintim: diagrame use case pentru interac țiunea utilizatorilor cu componentele
software, diagrama claselor pentru clasele statice și rela țiile dintre acestea, diagrame
de secven ță pentru comportamentul dinamic a instan țelor din diagramele claselor,
diagrame de stare pentru ilustrarea tranzi țiilor.
Suportul UML pentru definirea cerin țelor de securitate și a privilegiilor prin
aceste diagrame și a elementele lor constituente (exemplu: actori, s isteme, use case-
uri, clase, instan țe, rela ții, metode, date, etc) este precar [DDT +04] dar exist ă eforturi
de a le încorpora în UML: [ES99], [SA00] folosesc U ML ca pe un limbaj de
reprezentare a modelelor și nota țiilor RBAC; [J02], [J05] pentru defini ții teoretice ale
securit ății cu UML; [BDL03] introduce SecureUML pentru secur itate cu elemente de
meta-model; [R+03] a utilizat UML pentru a modela sisteme bazate p e MAC și
RBAC; [AW 103] și [AW 203] prezintă un cadru de încorporare a securit ății în use
case-uri.
Modelul SCAR-ACE încorporeaz ă cerin țele de securitate în diagrame use case,
de clase, de stare, de secven ță și de colaborare pentru definirea elementelor UML
relevante. Fezabilitatea acestor diagrame este demo nstrată prin implementarea
practic ă.
3.5.2 Nivele de securitate în acordarea privilegiil or
In MAC controlul accesului este bazat pe tupla ( s, op, o ) care indic ă faptul c ă
subiectul s poate executa opera ția op (unul sau mai multe procese) asupra obiectului
o. In timp ce aceast ă abordare este specific ă con ținutului bazelor de date rela ționale,
exist ă mai multe motive pentru care acest triplet ( s, op, o ) nu este corespunz ător
abord ării SCAR-ACE orientate obiect. In primul rând în MA C un obiect este o
instan ță caracterizat ă de mai multe atribute, care pot fi simple sau refe rin țe la alte
obiecte, fiecare având diferite caracteristici ale privilegiilor. In al doilea rând, opera ția
op reprezint ă în mod tipic un set de opera ții standard (citire, scriere, actualizare, etc)
asupra obiectului o, în timp ce metodele (opera țiile) unei clase OO con țin seturi
complexe de opera ții și sarcini.
Pentru abordarea SCAR-ACE propun utilizarea cvadrup lului ( si, s j, p, o ).
Aceast ă tupl ă desemnează trecerea de la starea si la starea sj și executarea opera ției o,
dac ă au fost îndeplinite permisiunile p. O stare încapsuleaz ă un obiect complex
(specific unui set de atribute ale unei interfe țe utilizator – o pagin ă sau un cadru).
44 Pentru realizarea tranzi ției trebuie îndeplinite anumite permisiuni specific ate prin p.
Trecerea la starea urm ătoare se realizeaz ă prin executarea unei opera ții o ce reprezintă
unul sau mai multe procese executate asupra obiecte lor implicate în trazi ție. Un
proces este mai mult decât o opera ție de citire sau scriere în baza de date acesta
putând con ține calcule complexe, verific ări de permisiuni, interac țiuni între tabele ale
bazei de date, servicii, etc.
In design-ul unui model de acordare a privilegiilor există diferite nivele de
abordare, nivele înglobate în proiectare și care se reg ăsesc apoi în aplica ția propriu-
zis ă. In cazul concret al sistemului SCAR-ACE exist ă diverse module care poart ă
amprenta restric țiilor de acordare a privilegiilor. [DD +04] introduce no țiunea de Nivel
de securitate pentru implementarea regulilor de asigurare a secu rit ății. O parte a
acestor nivele precum si unele specifice se reg ăsesc în modelul SCAR-ACE adaptate
pentru acordarea privilegiilor. Astfel în [OGI05] a m definit Nivelul 1 care se axează
pe diagramele de use case, Nivelul 2 care subliniaz ă leg ătura dintre clasele care se
utilizează pentru fiecare use case, și Nivelul 3 care reprezint ă crearea diagramelor de
stare, de secven ță și de colaborare cu interac țiunile dintre actori. In fiecare nivel m-am
concentrat pe constrângeri de genul ( si, s j, p, o ).
Nivelul 1 – diagrame use case
O diagrama use case este o colec ție de cazuri utilizator. Un caz utilizator (use
case) reprezint ă o descriere a comportamentului actorilor pentru o anumit ă parte a
aplica ției.
Un actor este o entitate extern ă care interac ționeaz ă cu sistemul software la un
anumit nivel pentru a reprezenta simularea evenimen telor posibile (procesele). In
cazul concret al modelului SCAR-ACE un actor poate fi asimilat unui utilizator care
are asignat un rol.
In diagrama de use case din figura 8 sunt prezenta ți doi actori: Vizitator și
Cump ărător și procesul de înregistrare/login pentru autentifica re. Practic în modelul
ierarhic RBAC cei doi actori sunt dou ă roluri aflate într-o rela ție de mo ștenire. Astfel,
permisiunile unui vizitator sunt mo ștenite de c ătre cump ărător (sunt incluse în cadrul
permisiunilor cump ărătorului).
Figura 8. Use case de înregistrare/login a unui viz itator
Se introduce no țiunea de permisiune ata șat ă unui actor ac și se noteaz ă cu ac.p .
Setul tuturor permisiunilor acordate actorului ac se noteaz ă cu ac.PMS . Deoarece în
SCAR-ACE un actor este asociat unui rol, permisiuni le ac.PMS ale actorului ac sunt
echivalente cu permisiunile PMS asociate rolului r: r.PMS . Valoarea lui r.PMS este
aleas ă de c ătre proiectant pe baza politicii de acordare a priv ilegiilor și reflect ă Cump ărător
(from Use Case View) Vizitator
(from Use Case View) Autentificare
(from RegistrationP) Succes
Inregistrare/Login Eroare
45 permisiunile PMS ale unui utilizator la implicarea sa într-un compo rtament al
aplica ției în momentul în care de ține rolul r (specific actorului ac ).
Se introduce Regula de acordare a privilegiilor în mo ștenirea rolurilor:
∀ actori ac m și ac n asocia ți rolurilor rm și respectiv r n,, r n mo ștene ște
privilegiile lui rm ⇔ rn.PMS ≥ rm.PMS sau ac n.PMS ≥ ac m.PMS .
Cu alte cuvinte permisiunile PMS ale rolului senior (actorului p ărinte) sunt cel
pu țin egale cu cele ale rolului junior (actorului fiu) .
In diagrama use case din figura 8 actorul Cump ărător mo ștene ște permisiunile
actorului Vizitator (le încapsuleaz ă) dup ă o autentificare cu succes.
In modelul SCAR-ACE un utilizator poate deschide o sesiune de lucru în rolul
cu permisiune minim ă (PMS minime).
Procesul ata șat opera ției de autentificare are drept rezultat fie permisi unea de
log-in sau înregistrare în caz de reu șit ă, fie semnalarea unei erori în caz de e șec.
Pentru a verifica regula emis ă s-a ales ca utilizatorul s ă î și deschid ă sesiunea de
lucru în rolul actorului vizitator care are permisiunea cea mai joas ă. Această restric ție
este impus ă și, oricare ar fi starea în care utilizatorul ar dor i s ă accead ă la ini țierea
unei sesiuni, el este redirec ționat c ătre starea vizitator cu permisiuni minime. Pentru a
intra în orice alt rol, utilizatorul trebuie s ă treacă printr-un proces de autentificare.
Când utilizatorul ia un rol al unui actor p ărinte ac m, prin mo ștenire, sunt necesare și
permisiunile actorului fiu ac n.
Nivelul 2 – diagrame de clase
O diagram ă de clase este alc ătuită din clase și reprezintă structura static ă a
modelului conceptual. O clas ă este abstractizarea unui set de obiecte care sunt
caracterizate de atribute și opera ții. In implementare, o clas ă este denumit ă obiect iar
opera ția unei clase este denumit ă metod ă. Interfe țele la alte modele sunt o
particularizare în cadrul diagramelor de clase. In figura 9 sunt reprezentate interfe țele
corespunzătoare rolurilor din figura 8 și a procesului de selec ție a rolurilor înainte și
dup ă autentificare:
Figura 9. Diagrama de clase: Interfe țe pentru selectarea rolurilor
In Nivelul 2 de securitate, pentru acordarea privil egiilor, se pune accentul pe
definirea claselor care sunt utilizate într-un use case. Acest pas este anterior celui
pentru dependen țele bazate pe mesajele care sunt definite în diagra ma de secven țe.
UML nu suport ă un tip explicit de diagram ă care s ă asocieze use case-urile cu clasele IMasinaStare
Eveniment()
IVizitator ICumparator IDistribuitor
Selectie()
IVanzator
46 care se utilizeaz ă pentru a-l implementa; are îns ă în mod implicit facilitatea de a alege
clasele care sunt implicate în diagrama de secven ță pentru a descrie activit ățile unui
use case.
Se introduce no țiunea de domeniu al permisiunilor DMP pentru clasa c care are
o valoare minim ă ( min ) și o valoare maxima ( max ) pentru metodele pe care le
implementează. Cu alte cuvine c.DMP min și c.DMP max specifică domeniul de
permisiuni al clasei c.
In Nivelul 2, pentru o clas ă c care se utilizeaz ă într-o diagram ă de secven ță
pentru a realiza func ționalitatea unui use case uc , DMP al uc trebuie s ă fie mai mare
decât cel al clasei/claselor pe care le con ține. Cu alte cuvinte domeniul permisiunilor
al uc înglobează toate domeniile de permisiuni ale claselor compone nte, având nivelul
de acordare a privilegiilor cel pu țin egal cu nivelul minim al claselor componente.
Se introduce Regula de acordare a privilegiilor în rela ția dintre Use Case și Clas ă.
∀ use case uc și clas ă c,
domeniul permisiunilor al uc relativ la c ⇔ uc.DMP ≥ c.DMP min .
De notat este faptul c ă Nivelul 2 reprezint ă stadiul ini țial, înaintea cre ări
diagramelor de secven ță , în care diagramele de clas ă sunt asociate cu use case-urile.
In acest moment sunt selectate clasele/obiectele f ără includerea dependen țelor între
metode.
Nivelul 3 – diagrame de stare, de secven ță și de colaborare
Diagrama de stare ilustreaz ă st ările, tranzi țiile între st ări și evenimentele
declan șatoare. O stare încapsuleaz ă mai multe propriet ăți (are ata șate diferite atribute)
și poate fi modificat ă în anumite condi ții (de obicei la apari ția unui eveniment).
Diagrama de stare din figura 10 ilustreaz ă o parte a ma șinii de stare și anume
ma șina de stare care controleaz ă autentificarea exemplificat ă în use case-ul din figura
8.
Figura 10. Diagrama de stare ce denot ă controlul accesului în autentificare ST_LOGIN
ST_REGISTER Esec Succes Succes
ST_PROFIL
47 O diagram ă de secven ță în UML reprezint ă comportamentul dinamic al
instan țelor (obiectelor) diagramei de clase. Pentru a real iza o anumit ă opera ție (adesea
un use case), diagrama de secven ță indică interac țiunea dintre obiecte. Scopul acestei
diagrame este de a modela fluen ța controlului, de a ilustra un scenariu tipic al
proces ării.
Figura 11. Diagrama de secven ță pentru determinarea creden țialului
Figura 11 exemplific ă diagrama de secven ță pentru ob ținerea creden țialului la
pentru autentificare. DAM : V MasinaStare Inreg B
D Sesiune
1: Start Inregistrare sau LogIn
2: Start User Engine
11: Start Proces Inregistrare 4: Test IDMasinaStare: unicitate
7: Trimite IDMasinaStare 5: Obtine IDMasinaStare
6: Trimite IDMasinaStare
9: Cere IDSesiune
10: Trimite IDSesiune
12: Proces Inregistrare/Sign In
13: Return Status
14: Proces Status (logs, user feed-back) 3: Genereaza IDMasinaStare
8: Daca ID ne-unic Goto 3
15: Verifica Time Out
48 In strâns ă corela ție cu aceast ă diagram ă de secven ță este diagrama de colaborare
ilustrat ă în figura 12.
Pentru prezentarea regulilor de acordare a privileg iilor este necesar ă furnizarea
unor nota ții adi ționale. Astfel, o metoda m definit ă în clasa c (denotat ă cu c.m ) este
implementarea unei opera ții pentru descrierea unui set de activit ăți specifice
proceselor clasei c. Fie c.M setul tuturor metodelor definite în c. In proiectarea OO,
presupunem c ă toate atributele clasei sunt implicit private (asi gur ă securitatea), fiind
modificate de metode publice sau private (nu pot fi modificate direct).
In continuare adopt nota țiile introduse în [ZM90] în care se definesc dou ă tipuri
disjuncte de metode în cadrul unei clase: mutatori care altereaz ă starea unei instan țe și
observatori care conserv ă starea unei instan țe. Astfel avem:
– c.M W = {c.m | c.m modific ă atributele unei clase} – mutatori;
– c.M ¬W = c.M \ c.M W – setul metodelor care nu modific ă atributele –
observatori.
Figura 12. Diagrama de colaborare în autentificare
Un element al c.M W respectiv c.M ¬W este numit metod ă mutabil ă, respectiv
imutabil ă și se notează MuM , respectiv IMuM .
Utilizând aceste metode se pot defini regulile de a cordare a privilegiilor într-o
diagram ă de secven ță pentru un actor ac respectiv un rol r.
Vizitator
RegM Interfa ța
Vizitator
Notif
M
DAM
BD 8. Verificare parola
Context Securitate
Se siuneM 1: Date autentificare
2: Decripteaz ă mesaj
4: Trimite parola
7: Trimite userInfo sau notOK 9: Sign in NotOK 8: Sign in OK 3: Trimite date autentificare 11: Form Autentificare
10: Sign in NotOK
5: Cere parola
6: Trimite userInfo sau notOK 12: Trimite K(Sesiune)
49 Se define ște Regula de acordare a privilegiilor pentru metoda un ei clase apelate
de un actor (implementarea permisiunilor PMS ale unui rol r de către clasa c).
∀ actor ac și metoda cj.my , ac utilizează în acordarea privilegiilor pe cj.m y ⇔
dac ă cj.m y ∈ cj.M ¬W : ac.PMS ≥ cj.m y.PMS.
sau
∀ rol r și metoda cj.my , permisiunile PMS ale rolului r sunt implementate și de
cj.m y ⇔ dac ă cj.m y ∈ cj.M ¬W : r.PMS ≥ cj.m y.PMS.
Astfel, pentru acordarea privilegiilor actorul care apelează o metod ă a unei clase
imutabile trebuie s ă aib ă permisiunea cel pu țin egal ă cu cea a metodei clasei.
Permisiunile unui rol implementat de o metod ă a unei clase sunt cel putin egale cu
permisiunile implementate de metod ă.
Se mai introduce o regul ă și anume Regula de acordare a privilegiilor pentru
metodele dintr-un Use-Case .
∀ use case uc și diagrama de secven ță Dsec , uc este descris de metodele din
Dsec ⇔ uc.DMP ≤ min ( ci1 .m x1 .PMS, …, c ik .m xk .PMS ) unde ci1 .m x1 .PMS, …,
cik .mxk .PMS ∈ c.M W și sunt utilizate în Dsec pentru a descrie ac țiunile din uc .
In această regul ă se specifică faptul c ă proiectantul nu poate utiliza într-un use
case uc metode mutabile cu permisiunile PMS mai mici decât cele ale uc .
Se define ște Regula de acordare a privilegiilor pentru o clas ă relativ la
metodele sale .
Astfel se introduc urm ătoarele no țiuni:
– c.DMP min ≤ min { c.m x.PMS metoda mx este definită în clasa c};
– c.DMP max ≥ max { c.m x.PMS metoda mx este definită în clasa c}.
Clasa c trebuie s ă aib ă cel pu țin o metod ă mutabil ă. Conform principiului celui
mai mic privilegiu, valoarea minim ă a domeniului privilegiilor clasei c are valoarea
maxim ă egal ă cu cea mai mic ă valoare a permisiunilor metodelor sale. Valoarea
maxim ă a DMP pentru o clasa c este cel pu țin egal ă cu maxima permisiunii metodelor
componente.
3.5.3 Politica de acordare a privilegiilor
Controlul accesului se refer ă la alocarea permisiunilor pentru fiecare rol.
Permisiunile rolurilor reprezint ă tuple <r, {s}> în care r este un rol iar {s} denot ă un
set de st ări.
PMS r = {<r, {s}> | r ∈ R, s ∈ S}
adic ă permisiunile PMS ale rolului r sunt asocieri între acel rol și st ările s
corespunz ătoare acestuia.
50 Pentru a exprima rela ția dintre elementele tuplei se define ște politica
conceptual ă de acordare a privilegiilor care afirm ă: “fiecare rol are permisiunea de a
accesa doar un anumit set de st ări date, între care sunt stabilite tranzi ții bine definite”.
In SCAR-ACE politica conceptual ă se refer ă la introducerea unei ma șini de
stare pentru acordarea de permisiuni fiec ărui rol, ma șin ă de stare care încapsuleaz ă
setul {s} de st ări pe care rolul r are autorizarea de a le accesa. Astfel, exist ă câte o
ma șin ă de stare pentru fiecare rol prin intermediul c ăreia se acord ă permisiunile,
ma șin ă de stare care urm ăre ște și fluen ța controlului. O interfa ță utilizator grafic ă
asociat ă unei st ări din setul {s} reprezint ă o stare în ma șina de stare M iar fiecare
tranzi ție reprezint ă un arc al acelei ma șini de stare.
Politica de securitate mai introduce o constrângere temporal ă asupra validit ății
unui creden țial și anume: “un creden țial nu poate fi valabil peste un timp t de la data
ultimei acces ări”.
In implementare, aceasta se reflect ă prin introducerea unei perioade t de
validitate a creden țialului dup ă ultimul acces la o resurs ă sau serviciu. In mod general
aceast ă perioad ă este acceptat ă a fi de 20 de minute.
3.5.4 Algebra politicii de acordare a privilegiilor
In cadrul politicii de acordare a privilegiilor se introduc diferite opera ții
algebrice pe tupla < r,{s}> și asupra creden țialelor, precum cele exemplificate mai jos:
a. Enumerarea – este suportat un set enumerativ de interfe țe utilizator grafice
{i} pentru fiecare rol. Intre aceste interfe țe exist ă o ordine care este
prestabilit ă (deci nu arbitrar ă) și nu exist ă posibilitatea acces ării aleatoare
a acestora. Exist ă o stare ini țial ă c ătre care un utilizator este redirec ționat
oricare alta ar fi adresa pe care acesta o solicit ă la ini țierea unei sesiuni de
lucru. Aceast ă stare este prima în cadrul setului enumerativ, se nume ște
Home și are gradul de securitate cel mai redus.
b. Adunarea (cu sensul de uniune ) este suportat ă în dou ă concepte diferite, și
anume:
– pentru tupla <r, {s}> în cadrul rela ției de mo ștenire între roluri: un
rol senior suport ă seturile {s} aferente tuturor rolurilor junior pe
care le moștene ște cât și setul {s} specific rolului senior pe care îl
de ține;
– în crearea creden țialelor: acestea sunt o concatenare a mai multor
identificatori (vezi și sec țiunea 3.6).
c. Sc ăderea sau mai general toate opera țiile care necesit ă lucrul cu “informa ții
negative” relativ la accesul la o resurs ă sau la un serviciu nu este
suportat ă. Aceasta nu se reg ăse ște nici în gestionarea st ărilor și nici în
lucrul cu creden țialele:
– pentru st ări: sunt accesate de c ătre un utilizator doar acele st ări pentru
care utilizatorul este autorizat, st ări care formeaz ă setul {s} și nu se
specific ă setul pentru care accesul este interzis (nu se spe cific ă
“st ările interzise”);
– pentru creden țiale: sunt acceptate creden țialele care întrunesc toate
condi țiile de acces și nu se specific ă creden țialele care nu sunt
acceptate. Mai exact: sunt specificate condi țiile necesare unui
51 creden țial în a fi acceptat și orice alt ă variant ă este respins ă prin
excludere.
d. Selec ția poate fi aplicat ă pentru creden țial și interpretat ă ca și separarea
identificatorilor din cadrul creden țialului, identificatori care satisfac
anumite constrângeri. Dac ă se consider ă c ă un creden țial este suma mai
multor identificatori ace știa sunt separa ți prin selec ție și testa ți individual,
în vederea satisfacerii condi țiilor de acces la o resurs ă sau serviciu. To ți
termenii componen ți ai unui creden țial trebuie s ă fie valizi.
3.6 Creden țiale
3.6.1 Componentele unui creden țial
Un creden țial este emis de fiecare dat ă când un utilizator cere accesarea unei
resurse sau a unui serviciu. Un creden țial se seteaz ă atât pe server cât și pe client și
con ține urm ătorii identificatori [O00]:
• identificator utilizator;
• identificator rol;
• identificator stare curent ă;
• identificator eveniment;
Identificator utilizator este un num ăr mare generat prin apelul unei func ții de
generare identificatori utilizator (GUID) și este valid pe toat ă durata unei sesiuni de
lucru. Este generat de server la ini țierea unei sesiuni de lucru și este transmis pe client
care, la rândul s ău îl trimite nealterat serverului. Orice modificare asupra acestui
identificator determin ă invaliditatea creden țialului și întreruperea sesiunii.
Identificator rol reprezintă rolul utilizatorului (sau echivalent identificator
ma șina de stare). Identificatorul este emis de c ătre server și este transferat clientului
care nu il poate modifica. Este în strâns ă corela ție cu urm ătorii termeni din cadrul
creden țialului: starea curent ă și evenimentul- și orice alterare în cadrul acestui tuplu
determin ă invaliditatea creden țialului. Aceasta deoarece fiec ărui rol i se confer ă un set
unic de st ări și fiecare stare poate fi modificat ă doar la apari ția anumitor evenimente.
Identificator stare curent ă denume ște în mod unic un set de atribute (o interfa ță
utilizator: o pagin ă sau un cadru). Acest termen face parte din grupul de permisiuni
acordate și, în func ție de valoarea tuplei (rol, stare curent ă, eveniment) se acord ă
dreptul de acces la anumite resurse și/sau servicii. Valoarea acestui identificator este
ini țiată de server care o trimite clientului iar acesta, la rândul s ău o retrimite
serverului. Similar celorlal ți identificatori, nici acesta nu poate fi modificat pe traseu
fără repercursiuni asupra validit ății creden țialului.
Identificator eveniment de modificare stare, este parte a acord ării drepturilor de
acces împreună cu identificatorii anteriori. Acest termen este em is pe partea de client
la ac ționarea unui element activ al interfe ței – de exemplu un meniu, un buton sau o
selec ție – și poate determina:
– modificare identificator rol prin trecerea la un no u rol;
– modificare stare curent ă – întotdeauna se trece la o nou ă stare (de exemplu
o nou ă interfa ță utilizator).
52 3.6.2 Prelucrarea creden țialelor
Pentru a realiza o aplica ție sigur ă aceasta trebuie s ă asigure printre altele și
urm ătoarele:
– să localizeze toate intr ările în sistem care pot fi manipulate de c ătre un
atacator;
– să stabileasc ă intr ările legale și s ă le rejecteze pe toate celelalte;
– să controleze fluen ța controlului.
Modelul SCAR-ACE realizeaz ă aceste cerin țe. Mecanismul de control se refer ă
la blocarea tuturor punctelor de intrare posibile p rin care un atacator poate avea
accces. In cazul unei aplica ții distribuite accesul se realizeaz ă prin linia de comand ă.
Prin urmare întregul control trebuie s ă porneasc ă de la aceast ă linie de comand ă prin
interpretarea acesteia. Linia de comand ă a SCAR-ACE este alc ătuit ă din creden țial și
parametrii cererii de acces.
In considerarea acestor amenin ță ri se presupune c ă exist ă puncte de intrare în
aplica ție prin care un atacator poate introduce valori mal i țioase.
SCAR-ACE, pentru a reduce posibilit ățile de atac, de ține credentialul în form ă
ascuns ă (linia de comand ă nu este în form ă explicit ă).
Orice cerere emis ă de c ătre un utilizator se traduce printr-o linie de coma nd ă
compus ă din creden țial și parametrii de apel, creden țial ale c ărui valori sunt în
corela ție în sensul c ă:
– unui rol îi corespund anumite st ări bine definite;
– dintr-o stare pot fi emise evenimente bine definite ;
– pentru fiecare cerere parametrii sunt specifici avâ nd num ărul și tipul bine
definiti.
Mai mult decât atât, linia de comand ă con ține informa ții diverse ilustrate în
figura urm ătoare.
Figura 13. Informa țiile liniei de comand ă
Serverul, la primirea unui creden țial îl interpreteaz ă progresiv, identificator cu
identificator. Prima validare pe care o face: verif ică dac ă identificatorul utilizatorului
este în memorie. In cazul unei erori (identificator utilizator inexistent) utilizatorul este Linia de comand ă
Date de identificare Date de proces
Identificator
utilizator Identificator
rol Identificator
stare Identificator
eveniment Parametri Creden țial
53 notificat și i se trimite o pagin ă de eroare cu un mesaj concludent prin care i se
specifică faptul c ă nu i se accord ă accesul la nici o resurs ă sau serviciu.
Dacă primul pas este trecut cu succes se verific ă identificatorul rolului și, în
func ție de rezultatul testului, fie se trece la pasul ur m ător în caz de succes fie se emite
o pagină de eroare. Dac ă identificatorul rolului este unul valid acesta est e trimis unei
componente de distribu ție (Dispacher) care d ă în prelucrare restul creden țialului
corespunz ător fiec ărui rol (vezi și figura 14).
Figura 14. Diagrama de procesare a creden țialului
Starea curentă este specifică fiec ărei ma șini de stare în parte și este un element
distinct în cadrul grafului de apel. Acest identifi cator, împreun ă cu identificatorul
rolului și cu evenimentul, dac ă sunt eronate, determin ă primirea de c ătre utilizator a
unui mesaj de acces nepermis. Dac ă aceste valori sunt corecte atunci se poate accesa
resursa sau serviciile cerute și se trece la starea urm ătoare. Valoarea acestei st ări noi
este clar definit ă și unică și serverul o determin ă din creden țial și parametrii primi ți și
o trimite clientului. Pentru client aceast ă stare va deveni starea curent ă.
Dintr-o stare curent ă nu se pot emite decât anumite evenimente în func ție de
elementele active ale interfe ței grafice utilizator. In func ție de valoarea evenimentului
se mai trimit serverului parametri suplimentari de apel. Ace ști parametri pot avea
valori variabile și reprezintă atribute obiect sau parametri de metod ă în realizarea
accesului cerut la resurs ă sau serviciu. Cu toate c ă este posibil ă transmiterea acestor
parametri ei nu fac parte din creden țial ci sunt practic valori ale cererii emise de cli ent
în accesarea resurselor sau a serviciilor.
Sursele de cuno știn țe ale modelului sunt divizate în mai multe grupuri și
cuprind diverse entit ăți implicate în cadrul procesului de identificare a punctelor
vulnerabile.
1. Prima dintre sursele de cuno știn țe o reprezint ă analizorul liniei de
comand ă care separ ă câmpurile constituente ale acesteia (ale liniei de
comand ă) pentru a le da o semnifica ție valid ă. In cazul unui e șec se emite
mesaj de eroare.
2. Sursa de cuno știn țe urm ătoare este lista utilizatorilor curen ți în cadrul
căreia se verific ă urm ătorul câmp de identificare și anume identificatorul
utilizatorului. In mod uzual acesta este un num ăr mare generat de c ătre
sistem și memorat în lista utilizatorilor care au o sesiune deschis ă pentru
rolul determinat. Este un câmp temporar valabil pe durata unei sesiuni Creden țial
ID utilizator
Vizitator Administrator Cump ărător Vânz ător Distribuitor
Selec ție Succes ID rol
54 care nu se p ăstreaz ă în mod persistent. Totodata acest modul verific ă atât
cardinalitatea cât și cazul de roluri mutual exclusive. In caz de succ es se
trece în modulul urm ător de verificare a datelor de proces.
3. Urm ătorul nivel care reprezint ă o surs ă de cuno știn țe este un modul
distribuitor care verific ă dac ă rolul utilizatorului este unul valid. In caz de
succes acesta distribuie câmpurile r ămase mai departe spre analiz ă și
acordarea accesului.
4. Grupul urm ător de cuno știn țe este alc ătuit din ma șina de stare specific ă
fiec ărui rol. Acest modul verific ă informa țiile de proces și permite accesul
la resursele solicitate de c ătre utilizator. Verificarea implic ă accesarea
bazei de date pentru validarea perechii <stare, eve niment>, dac ă este o
stare permis ă, dac ă are ata șat un serviciu sau dac ă necesit ă parametri. In
cazul în care sunt necesari, parametri verific ă dac ă ace știa respect ă
num ărul și tipul necesare. In caz de e șec se emite mesaj de eroare iar în
caz contrar, de succes, se trece la accesarea servi ciului cerut, rularea
acestuia și trecerea în starea urm ătoare.
3.7 Rolul interfe țelor grafice utilizator
In [P93] este introdus modelul interfe țelor utilizator inteligente care con ține
modulele detaliate în figura de mai jos.
Figura 15. Modelul de comunicare al interfe țelor inteligente
Există cerin țe de cunoa ștere a unor func țiuni suplimentare fa ță de cele
reprezentate în figura 15 care sunt necesare unei i nterfe țe utilizator inteligente [C89]
precum: cunoa șterea uneltelor software utilizate și a dispozitivelor hardware pentru
furnizarea modelului corespunz ător; cunoa șterea mediului organiza țional; interfa ța, pe
de altă parte, trebuie s ă asigure comunicarea cu utilizatorul, s ă-i realizeze sarcinile în
mod intuitiv.
Utilizând modelul abstract din figur ă se identific ă trei func ționalit ăți primare ale
interfe ței inteligente: modelarea opera țiilor, modelarea utilizatorului și transla ția.
Modelarea opera țiilor într-o interfa ță implică un model satisf ăcător care s ă
realizeze toate func ționalit ățile importante. Modelarea utilizatorului implic ă
realizarea unei reprezent ări a cuno știn țelor pentru opera țiile existente. Transla țiile
convertesc inten țiile utilizatorului în opera ții, și opera țiile în răspunsuri identificabile.
Aceste func țiuni implica cunoa șterea cerin țelor: cunoa șterea opera țiilor și a
domeniilor, cunoa șterea tipurilor de utilizatori și cunoa șterea modalit ăților de
interac țiune. Aceste cerin țe adresează interac țiunea dintre un utilizator și o aplica ție.
O alt ă abordare a interfe țelor grafice utilizator este în func ție de feedback-ul
acestora relativ la un domeniu. Figura urm ătoare descrie procesul de feedback a
interfe țelor utilizator din punct de vedere al fluen ței controlului și modul de clasificare
al acestora în adaptive și neadaptive. Utilizator Ma șina
opera țiilor Comunicarea
cu utilizatorul Opera ții
55
Figura 16. Trei tipuri de sisteme de feedback
In figura 16 se definesc trei tipuri de interac țiuni între un domeniu D și
interfe țele I care îl acceseaz ă. In accep țiunea SCAR-ACE, un domeniu D reprezintă
opera țiile posibil a fi realizate pentru un anumit rol ia r interfe țele I reprezintă
interfe țele grafice prin care utilizatorul comunic ă cu aplica ția.
In figura 16 sistemul (a) este neadaptiv deoarece i nterfa ța I nu prime ște nici un
feedback de la domeniul D. Sistemul (b) este adaptiv și interfa ța comunică cu
domeniul. Sistemul (c) este de asemenea adaptiv dar interfa ța se modifică în urma
comunic ării cu domeniul.
In realizarea constrângerilor de autorizare din SCA R-ACE se utilizeaz ă interfe țe
neadaptive (cele de tip (a)) deoarece acestea sunt definite în faza de design și nu î și
pot modifica atributele constituente ci doar valori le acestora. Aceste interfe țe nu pot fi
clasificate în mod neap ărat ca fiind inteligente. In schimb pot fi califica te ca având
cuno știn țe relativ la sistemul pe care îl sus țin. Aceste cuno știn țe sunt încapsulate în
st ări și evenimente declan șatoare ale tranzi țiilor. Din punct de vedere al
adaptabilit ății, o stare reprezint ă instan ța unei interfe țe sau a unei părți a acesteia și,
împreună cu un eveniment, și în urma comunic ării cu domeniul, determin ă trecerea la
interfa ța urm ătoare.
Domeniul D este o colec ție de opera ții și o tranzi ție se execută dac ă cererea este
autorizat ă. Mecanismele de navigare între st ări sunt implementarea opera țiilor prin
controlul exercitat de ma șina de stare.
Intregul sistem este, în schimb, unul pseudo-inteli gent deoarece ac țiunea
urm ătoare a unui utilizator se realizeaz ă prin inferen ța cu cea anterioar ă [M+92].
Pentru a fi interfe țe complet inteligente ar trebui s ă participe la un proces de înv ățare
dar aceste interfe țe doar recunosc șabloane într-o secven ță de interac țiuni și stabilesc
pasul urm ător.
(a) (b) (c) Interfa ța
Domeniu I1
D I1
D I1
D I2
56 3.8 Controlul accesului
3.8.1 Ma șina de stare
In lucrarea de fa ță propun un model pentru controlul accesului în apli ca țiile de
comer ț electronic pe baza uneia sau a mai multor ma șini de stare. In mod extins orice
aplica ție are o secven ță de opera ții (procese) și impunerea unei ordini asupra acestora
determin ă posibitatea trat ării prin mașini de stare.
Voi nota cu:
– U, R și A setul de utilizatori, setul de roluri și respectiv setul de ac țiuni în
cadrul unui sistem distribuit.
– M, S și T pentru ma șina de stare, st ări și respectiv tranzi ții între st ări.
Conform [BFA98] o ma șin ă de stare este o listă de st ări, tranzi ții și opera ții
specifice unui rol. Tranzi țiile le notez cu [T 1, T 2, …, T n] unde fiecare T este o 3-tupl ă:
T = < Ai, (RS i, >i), act i>
unde:
Ai ∈A,
RS i⊆R este un set de roluri autorizate s ă execute Ai,
>i este o ordine local ă a rolurilor
act i reprezintă num ărul posibil de activ ări ale ac țiunii Ai.
Definirea no țiunii de ma șin ă de stare într-un sistem distribuit conform [GHS95]
determin ă ca în condi țiile în care suprapunem peste un model distribuit o ordine
(par țial ă sau total ă) acesta poate fi tratat prin intermediul ma șinilor de stare care
modelează și controlează execu ția proceselor într-o aplica ție distribuit ă. Fiecare
tranzi ție este definit ă ca și un set de opera ții coordonate care se execut ă în vederea
ob ținerii anumitor rezultate. O ac țiune poate fi alc ătuit ă din mai multe procese și
realizeaz ă deservirea unei cereri prin accesul la o resurs ă sau un serviciu. Ac țiunile
într-un sistem distribuit peste care este suprapus ă o ordine, sunt interdependente
reflectând o activitate coordonat ă.
In mod tipic o organiza ție stabile ște un set de politici de securitate care impun
reguli asupra modului în care se gestioneaz ă resursele și serviciile. In timp ce o
politică simpl ă poate specifica rolul c ăruia i se poate asigna o ac țiune, o politic ă
complex ă poate specifica constrângeri de autorizare precum separarea îndatoririlor.
La execu ția unei tranzi ții ac țiunile sunt asignate rolurilor pe baza unei
specifica ții explicite a regulilor de autorizare. Constrânger ea de separare a
îndatoririlor asigur ă faptul ca este interzis ca unui singur utilizator să i se dea
autoritate suficient ă astfel încât s ă poată să fraudeze sistemul [AW05].
In [BFA98] se examineaz ă diferite tipuri de constrângeri ale autoriz ării
(incluzând cele statice, dinamice și hibride) și se propun solu ții de asignare a
ac țiunilor la utilizatori, într-un sistem bazat pe rol uri, astfel încât s ă nu fie violate
constrângerile autoriz ării. In continuare abordez aceast ă tematică în contextul
aplica țiilor de comer ț electronic pe baza ma șinilor de stare.
57 3.8.2 Rolurile
In modelul SCAR-ACE impun o secven țialitate a opera țiilor în condi țiile în care
exist ă constrângeri.
Spre deosebire de aplica țiile în care un utilizator poate avea mai multe rol uri
autorizate în cadrul unei sesiuni, în aplica țiile care necesita controlul accesului fiecare
utilizator are un singur rol autorizat, explicit as ignat dup ă autentificarea prin nume și
parol ă.
Introduc clasificarea urm ătoare asupra rolurilor în func ție de tipul accesului:
• roluri publice;
• roluri private.
In definirea rolurilor raportarea se face la aplica ția de comer ț electronic, un rol
fiind public respectiv privat în raport cu aceasta. Rolurile publice le definesc ca fiind
acele roluri cu acces din afara sistemului (de exem plu vânz ător, cump ărător,
vizitator).
Rolurile private sunt acele roluri controlate de c ătre sistem, asignate de c ătre
inginerul de sistem unor utilizatori cunoscu ți într-un cadru închis. De exemplu
recepționerul cererii sau expeditorul produsului au rolur i private.
In contextul lui R chiar dac ă un utilizator nu poate avea mai multe roluri, un
anumit rol poate fi jucat de c ătre mai mul ți utilizatori. Aceast ă facilitate, într-o
aplica ție distribuit ă, este posibil ă doar pentru rolurile publice. De exemplu, rolul de
cump ărător poate fi avut de c ătre mai mul ți utilizatori. Pentru roluri precum vânz ător
sau cump ărător utilizatorii sunt mai mul ți, sunt anonimi și nu pot fi nominaliza ți.
Cardinalitatea utilizatorilor asigna ți rolurilor private este, de cele mai multe ori, eg al ă
cu 1 sau cu o valoare știut ă și finit ă. Utilizatorii rolurilor private sunt de obicei
cunoscu ți și nominaliza ți. De exemplu, pentru rolul de administrator al sis temului este
asignat un utilizator, pentru recep ționerul unei cerereri este asignat unul sau mai mul ți
utilizatori.
Din punct de vedere al drepturilor detinute exist ă:
– utilizatori autoriza ți;
– utilizatori neautoriza ți.
Utilizatorii autoriza ți au acces la func țiile aplica ției de comer ț electronic prin
perechea nume_utilizator și parol ă pe când cei neautoriza ți sunt acei utilizatori care
folosesc facilit ăți pentru care nu este necesar ă autorizarea.
Intre roluri exist ă o ierarhie, o ordine par țial ă „>” care încadreaz ă aplica ția într-
un sistem RBAC 2. Dacă Ri și Rj ∈R sunt roluri, se nume ște c ă Ri domină pe R j dac ă
Ri > R j. Intre aceste roluri este definit ă rela ția de moștenire în sensul c ă rolul dominant
mo ștene ște func ționalit ățile ale rolului dominat. In cadrul exemplului pract ic rolurile
de vânz ător și cump ărător domină rolul de vizitator și încapsuleaz ă toate facilit ățile
oferite acestuia.
In afara acestor roluri între care exist ă o rela ție global ă există roluri pentru care
nu este impus ă o rela ție, de exemplu recep ționerul unei cereri nu este subordonat ca și
func ționalitate unui alt rol ci acesta trebuie doar s ă respecte ordinea opera țiilor impus ă
de c ătre aplica ție și s ă se încadreze în restric țiile temporale (de exemplu nu poate
58 interveni înaintea depunerii unei cereri și, dacă o cerere a fost emis ă, el are un timp
rezervat bine stabilit în care s ă o solu ționeze pozitiv sau negativ).
3.8.3 Constrângeri ale rolurilor și ale asign ărilor utilizator
Constrângerile aplicate asupra utilizatorilor și asupra asign ărilor rolurilor la un
set de permisiuni pot fi de câteva tipuri, clasific ate în literatura de specialitate [GI96],
[AS00], [SC96] în trei categorii în func ție de momentul evalu ării acestora:
(1)Constrângeri statice – acestea pot fi evaluate în afara execu ției aplica ției
distribuite. Exemplu de constrângeri statice ar fi: „cel pu țin trei roluri pot
fi asociate unei aplica ții”.
(2)Constrângeri dinamice – pot fi evaluate doar în timpul execu ției
aplica ției. Acestea sunt constrângerile de control al acce sului.
(3)Constrângeri hibride – constrângeri care pot fi par țial verificate în afara
execut ării aplica ției și par țial verificate în timpul execut ării aplica ției. O
astfel de constrângere ar fi cea conform c ăreia un utilizator care execut ă o
ac țiune A 1 nu poate executa o alt ă ac țiune A 2.
3.9 Definirea formala a modelului
3.9.1 Defini ții și termeni
In [BFA98] Bertino et all definesc un model formal pentru o aplica ție de sine
st ătătoare. In lucrarea de fa ță modific și extind acest formalism în cadrul modelului
SCAR-ACE care realizeaz ă controlul accesului în aplica țiile de comer ț electronic.
Pentru definirea formala a modelului SCAR-ACE am re alizat un limbaj de
exprimare a constrângerilor de autorizare [OG 107]. Acest limbaj de specificare a
constrângerilor asupra controlului accesului define ște un set de simboluri constante,
variabile și predicate.
Defini ția 23 : O constantă poate fi orice membru al uneia dintre urm ătoarele mul țimi:
U (setul de utilizatori), R (setul de roluri), A (setul de ac țiuni), S (setul de st ări), E
(setul de evenimente), T (setul de tranzi ții) și P (setul de parametri).
Astfel sistemul definit lucreaz ă cu constante din toate aceste tipuri (de exemplu
rolurile constante R_VIZITATOR, R_CUMPARATOR, R_REC EPTIONER ∈R,
st ările constante ST_HOME, ST_VIEW ∈S și evenimentele constante EV_HOME,
EV_VIEW, EV_SELECT ∈E).
Defini ția 24 : Pentru fiecare set de constante se define ște tipul variabil. Astfel există
șapte seturi de variabile notate cu V U, VR,, V A, V S, V E, V T și V P.
Variabilele pot fi cel mai u șor exemplificate pentru cele de tip rol și anume un
utilizator intr ă în cadrul sistemului în mod obligatoriu pe un rol de securitate redus ă
(exemplu R_VIZITATOR) și, la login, el comut ă pe un rol cu securitate mai mare
(exemplu R_CUMPARATOR) variindu- și astfel starea și modificându- și rolul.
59 In continuare voi nota cu UT termenii utilizator ca re definesc atât constantele
cât și variabilele utilizator UT = U ∪VU. Similar RT, AT, ST, ET, TT, PT denot ă
seturile V R∪R, VA∪A , VS ∪S, VE ∪E, VT ∪T și respectiv VP∪P.
Un alt set de elemente utilizate în cadrul definiri i formale a modelului SCAR-
ACE sunt predicatele. Astfel, exist ă mai multe seturi de predicate:
– un set de predicate de specifica ție care definesc modelul formal al
aplica ției distribuite (tabelul 1);
– un set de predicate de planificare care realizeaz ă restric țiile impuse de
constrângeri asupra seturilor de rol/utilizator car e pot executa o opera ție
(tabelul 2);
– un set de predicate de execu ție pentru execu ția aplica ției (tabelul 3).
Tabelul 1. Predicate de specifica ție
Predicat Definire
rol dacă rol (ri) este adev ărat atunci r i ∈ RT
utilizator dacă utilizator (u i) este adev ărat atunci u i ∈ UT
stare dacă stare (s i) este adev ărat atunci s i ∈ ST
eveniment dacă eveniment (e i) este adev ărat atunci e i ∈ ET
tranzi ție dacă tranzi ție (s i, s j, tk) este adev ărat atunci ∃ st ările s i, s j ∈ ST
pentru care este definit ă tranzi ția t k ∈ TT
parametru dacă parametru (t i, p j) este adev ărat atunci tranzi ția t i ∈ TT
necesit ă parametrul p j ∈ PT
apar ține dacă apar ține (u i, r j) este adev ărat atunci utilizatorul u i ∈ UT are
rolul r j ∈ RT
> dacă ri > r j atunci rolul r i mo ștene ște toate func ționalit ățile lui r j sau,
cu alte cuvinte, r i domină pe r j în ordinea rolurilor
60 Tabelul 2. Predicate de planificare
Predicat Definire
cannot_do r dac ă cannot_do r ( ri, a j) este adev ărat, atunci ac țiunea aj nu
poate fi asignat ă rolului ri
cannot_do t dac ă cannot_do t ( tm, si, s j) este adev ărat, atunci tranzi ția tm
din starea si în starea sj nu poate fi realizat ă
Must_execute r dac ă must_execute r ( ri, a j) este adev ărat, atunci ac țiunea aj
trebuie s ă fie executat ă de c ătre un utilizator apar ținând rolului ri
Must_execute t dac ă must_execute t ( tm, s i, s j) este adev ărat, atunci tranzi ția
tm trebuie s ă fie executat ă din starea si în starea sj
check dac ă check ( ti, s j, s k) este adev ărat ă atunci constrângerile legate
de tranzi ția ti din starea sj în starea sk pot fi verificate în afara
executiei aplica ției
panic dac ă panic este adev ărat ă atunci exist ă cel pu țin o constrângere
care nu poate fi satisf ăcut ă
Tabelul 3. Predicate de execu ție
Predicat Definire
exec u Dacă exec u(u i, aj, s k, e l) este adev ărat, atunci ac țiunea aj este executat ă de
utilizatorul ui prin comutarea de la starea sk la apari ția evenimentului el
exec r Dacă exec r(r i, aj, s k, e l) este adev ărat, atunci ac țiunea aj este executat ă de
utilizatorul apar ținând rolului ri prin comutarea de la starea sk la apari ția
evenimentului el
exec t Dacă exec t(r i, t j, s k, e l, pn) este adev ărat, atunci tranzi ția tj este executată
de utilizatorul apar ținând rolului ri prin comutarea de la starea sk la apari ția
evenimentului el și cu parametrii pn.
abort Dacă abort ( aj, s k, e l, p n) este adev ărat atunci ac țiunea ai nu a putut fi
executat ă cu succes la comutarea din starea sk, la apari ția evenimentului el.
Acesta se poate întâmpla fie dac ă evenimentul el nu este definit pentru
starea sk, fie dac ă parametrii pn nu sunt corespunz ători.
succes Dacă succes ( aj, s k, e l, pn) este adev ărat atunci ac țiunea ai a putut fi
executat ă cu succes la trecerea din starea sk la apari ția evenimentului el cu
parametrii pn.
61 3.9.2 Definirea regulilor
Conform [L89] o regul ă este o expresie de forma:
H ← A 1, … , A n not B1, … , not B m , n,m ≥ 0
unde
A1, … , A n și B1, … , B m sunt atomi și not denotă negarea prin e șec.
H este capul regulii iar A1, … , A n not B1, … , not B m sunt corpul acesteia.
In cadrul limbajului utilizat pentru definirea mode lului SCAR-ACE exist ă mai
multe categorii de reguli în func ție de predicatele accesate.
Defini ția 25 : O regul ă explicită este de forma H ← în care H este fie un predicat de
specifica ție fie unul de execu ție.
Regulile explicite reprezint ă fapte și corpul acestora este totdeauna vid.
Regulile explicite al c ăror cap este un atom de specifica ție determin ă definirea
partii statice a modelului. Sunt definite astfel ro lurile, utilizatorii, starile,
evenimentele, parametrii si tranzitiile corespunzat oare modelului.
De exemplu:
rol (R_VIZITATOR) ←
rol R_CUMPARATOR) ←
definesc doua roluri valide specifice aplicatiei.
Regulile explicite al c ăror cap este un atom de execu ție sunt generate de c ătre
sistem în timpul execu ției aplica ției.
De exemplu:
exec t(ri, t j, s k, e l, pn)
ilustreaz ă tranzi ția tj pentru rolul ri.
Defini ția 26 : O regul ă de atribuire este de forma:
H ←L1, …, L n , n ≥ 0
unde
H este fie must_execute r, must_execute t, cannot_do r,
cannot_do t,
Li este un atom de specifica ție sau un atom de execu ție .
O regul ă de atribuire exprim ă restric ții asupra unui set de utilizatori/roluri care
pot realiza o anumit ă tranzi ție. Regulile must_execute r și must_execute t
exprim ă necesitatea execu ției unei ac țiuni sau a unei tranzi ții pentru asigurarea
consisten ței constrângerilor. In mod similar, dar în sens con trar sunt regulile
cannot_do r și cannot_do t.
62 Defini ția 27 : O regul ă de verificare este de forma:
check ( ti, sj, s k) ←L1, … L n
unde
Li este un atom de specifica ție corespunz ător unei tranzi ții
Această regul ă verifică constrângeri iar în cazul modelului SCAR-ACE acest ea
sunt reprezentate de c ătre tranzi ții. In cazul în care constrângerea poate fi verific ată în
afara aplica ției atunci verificarea este static ă.
Defini ția 28: O regul ă static ă este o regul ă care poate fi evaluat ă fără a se executa
aplica ția.
Defini ția 29 : O regul ă dinamic ă este o regul ă explicită care poate fi evaluat ă doar în
timpul execu ției aplica ției.
In general exist ă o ordine par țial ă a rolurilor și exist ă tranzi ții specifice fiec ărui
rol. In anumite cazuri îns ă (similar celui descris în figura 17) nu se aplic ă nici o ordine
asupra rolurilor care execut ă anumite tranzi ții, și orice rol poate executa acea tranzi ție.
In acest caz tranzi ția este asociat ă ma șinii de stare vizitator ale c ărei tranzi ții sunt
mo ștenite de c ătre toate rolurile publice autorizate.
In condi țiile în care fiecare tranzi ție are ata șat un rol, se pot defini ma șinile de
stare specifice rolurilor:
Defini ția 30 (ma șina de stare): O specifica ție de ma șin ă de stare M este o list ă de
tranzi ții [t 1, t2, …,t n] în care fiecare tranzi ție ti este specificat ă printr-o tupl ă alc ătuit ă
din:
• rolul autorizat în efectuarea tranzi ției;
• starea ini țial ă s i și starea final ă s j;
• evenimentul e k;
• parametrii p r, … p q.
sau altfel spus
Defini ția 31 : Fie t = [t 1, …,t n] secven ța dat ă a tranzi țiilor. Ma șina de stare a modelului
este un graf etichetat G = (N,A) definit dup ă cum urmeaz ă:
(1) N – Noduri . Fiecare nod în G reprezint ă o stare s i în care stare(s i) este
adev ărat și s i ∈ ST;
(2) A – Arcuri . Fiecare arc în G reprezint ă o tranzi ție t i∈ TT care este
etichetat ă cu evenimentul declan șator e j ∈ ET, are drept start o stare s k și
se termin ă într-o alt ă stare s e, (s k , se) ∈ ST iar pentru execu ție are nevoie
de parametrii de intrare p m ∈ PT.
Defini ția 32: Modelul sistemului SCAR-ACE denotat M_M este alc ătuit din setul
ma șinilor de stare și constrângerile corespunz ătoare.
3.9.3 Exemplificare
Modelul formal de control al accesului este ilustra t pe cazul din figura 17. In
acest exemplu se selecteaz ă dou ă obiecte și atributele aferente acestora, dup ă care se
63 realizeaz ă o comparare între obiectele selectate. St ările sunt s 0, s1, s2, s3, s4 și s5.
Constrângerea const ă în impunerea unei secven țialit ăți între st ări prin tranzi țiile
marcate cu s ăge ți și se refer ă la imposibilitatea compar ării acestor obiecte f ără o
selectare preliminar ă a acestora. Fiecare obiect are ata șate atribute implicite deci
selectarea unor alte atribute nu este obligatorie.
Nu există nici o constrângere relativ la rolul pe care trebu ie s ă-l aib ă utilizatorul
în momentul efectu ării acestei compara ții, deci oric ărui rol i se ofer ă această facilitate,
motiv pentru care aceste tranzi ții sunt asignate rolului cu prioritate minim ă
(R_VIZITATOR). Constrângerile în cadrul exemplului considerat se implementeaz ă
prin tranzi țiile dintre st ări.
Astfel, exemplul poate fi descris la modul detaliat astfel:
– Tranzi ția t 1: Utilizatorul selecteaz ă obiectul 1. Sistemul se g ăse ște în starea
s1 prin tranzi ția din s 0 la apari ția evenimentului EV_START. Este o
tranzi ție obligatorie;
– Tranzi ția t 2: Utilizatorul ac ționează un element activ al interfe ței grafice si
selecteaza atributele primului obiect. Se emite eve nimentul
EV_SET_ATRIB și sistemul realizeaz ă tranzi ția din starea s 1 în starea s 2.
Este o tranzi ție op țional ă;
– Tranzi ția t 3: Utilizatorul ac ționează un element activ al interfe ței grafice
prin care se continu ă selectarea altor atribute pentru primul obiect. Se
emite evenimentul EV_SET_ATRIB și sistemul r ămâne în starea s 2. Se
trimit parametrii care specific ă atributul selectat. Este o tranzi ție op țional ă;
– Tranzi ția t 4: Utilizatorul ac ționează un element activ al interfe ței grafice
prin care se trece la selectarea obiectului al doil ea. Se emite evenimentul
EV_GET_OBJECT și sistemul realizeaz ă tranzi ția din starea s 2 în starea
s3. Inaintea realiz ării tranzi ției este ata șat obiectului 1 atributul/atributele
selectate (prin parametrii ata șati tranzi ției). Este o tranzi ție obligatorie dac ă
s-a ajuns în starea s 2 și s-a terminat selectarea atributelor primului obie ct;
– Tranzi ția t 5: Utilizatorul ac ționeaz ă un element activ al interfe ței grafice
prin care se trece la selectarea obiectului al doil ea f ără selectarea
atributelor (r ămân cele implicite). Se emite evenimentul
EV_GET_OBJECT și sistemul realizeaz ă tranzi ția din starea s 1 în starea s 3.
Este o tranzi ție obligatorie dac ă nu se dore ște selectarea atributelor pentru
primul obiect;
– Tranzi ția t 6: Utilizatorul ac ționeaz ă un element activ al interfe ței grafice
prin care se selecteaz ă atributele pentru cel de-al doilea obiect. Se emit e
evenimentul EV_SET_ATRIB și sistemul realizeaz ă tranzi ția din starea s 3
în starea s 4. Este o tranzi ție op țional ă;
– Tranzi ția t 7: Utilizatorul ac ționeaz ă un element activ al interfe ței grafice
prin care se continu ă selectarea altor atribute pentru obiectul al doile a. Se
emite evenimentul EV_SET_ATRIB și sistemul r ămâne în starea s 4. Se
trimit parametrii care specific ă atributele selectate. Este o tranzi ție
op țional ă;
– Tranzi ția t 8: Utilizatorul ac ționeaz ă un element activ al interfe ței grafice
prin care se trece la compararea între primul și cel de-al doilea obiect
selectat. Se emite evenimentul EV_COMPARE și sistemul realizeaz ă
tranzi ția din starea s 4 în starea s 5. Inaintea realiz ării tranzi ției sunt ata șate
obiectului 2 atributele selectate (parametrii ata șati tranzi ției). Este o
tranzi ție obligatorie dac ă s-a ajuns în starea s 4 și s-a finalizat selectarea
atributelor celui de-al doilea obiect;
64 – Tranzi ția t 9: Utilizatorul ac ționeaz ă un element activ al interfe ței grafice
prin care se trece la compararea între primul și cel de-al doilea obiect, f ără
selectarea atributelor celui de-al doilea obiect. S e emite evenimentul
EV_COMPARE și sistemul realizeaz ă tranzi ția din starea s 3 în starea s 5.
Este o tranzi ție obligatorie dac ă nu se dore ște selectarea atributelor celui
de-al doilea obiect.
Figura 17. Exemplu de ma șin ă de stare pentru selectarea a dou ă obiecte în
vederea compar ării lor
In continuare ilustrez specificarea tranzi țiilor t1–t9 în conformitate cu defini ția
30 pentru compararea a dou ă obiecte:
M = [(t 1, R_VIZITATOR, (s 0, s1, EV_START, {})),
(t 2, R_VIZITATOR, (s 1, s2, EV_SET_ATRIB, {param_ob 1})),
(t 3, R_VIZITATOR, (s 2, s2, EV_SET_ATRIB, {param_ob 1,
param_atrib 1})),
(t 4, R_VIZITATOR, (s 2, s3, EV_GET_OBJECT, { param_ob 1,
param_atrib 2})),
(t 5, R_VIZITATOR, (s 1, s3, EV_GET_OBJECT, {param_ob 1,
param_atrib 3})), s1
Selectare
obiect_1 EV_SET_ATRIB s2
Selectare
atribut
obiect_1 EV_SET_ATRIB
s4
Selectare
atribut
obiect_2 EV_GET_OBJECT
s3
Selectare
obiect_2 EV_SET_ATRIB
s5
Comparare
obiect_1 cu
obiect_2 EV_COMPARE EV_COMPARE EV_GET_OBJECT s0
Start
EV_START
EV_SET_ATRIB
65 (t 6, R_VIZITATOR, (s 3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2})),
(t 7, R_VIZITATOR, (s 4, s4, EV_SET_ATRIB, {param_ob 1, param-
atrib 2|3 , param_ob 2, param-atrib 4})),
(t 8, R_VIZITATOR, (s 4, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 5})),
(t 9, R_VIZITATOR, (s 3, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 6}))]
Considerând restric țiile impuse de tranzi țiile t1-t9 se pot ilustra constrângerile
CM(M) ale ma șinii de stare M construindu-se astfel modelul M_M a l SCAR-ACE.
Exemplific pe constrângerile tranzi țiilor din s 1 în s 4, din s 1 în s 5, din s 2 în s 4 și din s 2 în
s5.
CM1-4: cannot_do t (t10, s1, s4) ←
(exec t(R_VIZITATOR, t 2, s1, s2, EV_SET_ATRIB, {param_ob 1}) &
exec t(R_VIZITATOR, t 4, s2, s3, EV_GET_OBJECT, {param_ob 1,
param_atrib 2}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2})) |
(exec t(R_VIZITATOR, t 5, s1, s3, EV_GET_OBJECT, {param_ob 1,
param_atrib 3}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}))
CM1-5: cannot_do t (t 11 , s1, s5) ←
(exec t(R_VIZITATOR, t 2, s1, s2, EV_SET_ATRIB, {param_ob 1}) &
exec t(R_VIZITATOR, t 4, s2, s3, EV_SET_ATRIB, {param_ob 1,
param_atrib 2}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}) &
exec t(R_VIZITATOR, t 8,(s4, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 5})) |
(exec t(R_VIZITATOR, t 5, s1, s3, EV_GET_OBJECT, {param_ob 1,
param_atrib 3}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}) &
exec t(R_VIZITATOR, t 8, s4, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 5})) |
(exec t(R_VIZITATOR, t 5, s1, s3, EV_GET_OBJECT, param_ob 1,
param_atrib 3}) &
66 exec t(R_VIZITATOR, t 9,(s3, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 6}))
CM 2-4: cannot_do t (t 12 , s2, s4) ←
(exec t(R_VIZITATOR, t 4, s2, s3, EV_SET_ATRIB, {param_ob 1,
param_atrib 2}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}))
CM 2-5: cannot_do t (t 13 , s1, s5) ←
(exec t(R_VIZITATOR, t 4, s2, s3, EV_SET_ATRIB, {param_ob 1,
param_atrib 2}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}) &
exec t(R_VIZITATOR, t 8, s4, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 5})) |
(exec t(R_VIZITATOR,t 4, s2, s3, EV_GET_OBJECT, {param_ob 1,
param_atrib 2}) &
exec t(R_VIZITATOR, t 6, s3, s4, EV_SET_ATRIB, {param_ob 1,
param_atrib 2|3 , param_ ob 2}) &
exec t(R_VIZITATOR, t 9, s3, s5, EV_COMPARE, {param_ob 1,
param_atrib 2|3 , param_ob 2, param_atrib 6}))
3.9.4 Consisten ța specific ării modelului
Un model este specificat într-o manier ă consistent ă dac ă constrângerile
încapsulate pot fi satisf ăcute. Consisten ța specifica ției SCAR-ACE este determinat ă
prin analizarea acestui model (a ma șinilor de stare și a constrângerilor aplicate asupra
acestora).
In primul rând dac ă predicatul panic apar ține modelului aceasta implic ă
existen ța cel pu țin a unei condi ții care nu poate fi satisf ăcut ă. Din acest motiv, prima
condi ție de consisten ță a specifica ției impune ca predicatul panic s ă nu apar țin ă
modelului.
O altă etap ă trebuie s ă implice analizarea modelului astfel încât s ă nu con țină
informa ții contradictorii. De exemplu, dac ă ambele predicate must_execute t
(tm, si, sj) și cannot_do t (tm, si, s j)apar țin modelului, implic ă
constrângeri în cadrul acestuia care sunt inconsist ente deoarece sunt contradictorii.
O constrângere important ă este cea prin care s ă existe întotdeauna cel pu țin un
utilizator apar ținând unui rol permis care s ă poată realiza o ac țiune dat ă.
Pentru verificarea inexisten ței informa țiilor contradictorii trebuie realizat ă
computa ția tranzi țiilor care trebuie s ă fie permise/nepermise pentru un rol. Aceast ă
verificare implic ă baleierea bazei de date care con ține ma șinile de stare și verificarea
tranzi țiilor introduse. Astfel se deosebesc urm ătoarele seturi:
67 – Tranzi ții_Nepermise ™ = ∪ { t m | cannot_do t (tm, si, s j) ∈
M_M}. Tranzi ții_Nepermise reprezintă setul de tranzi ții care nu pot fi
executate în M_M conform ma șinilor de stare;
– Tranzi ții_Permise ™ = ∪ { t m | must_do t (tm, si, s j) ∈ M_M}.
Tranzi ții_Permise reprezintă setul de tranzi ții care pot fi executate în
M_M conform ma șinilor de stare;
– Roluri_Nepermise (r i) = ∪ { r i | cannot_do r (ri, aj) ∈ M_M}.
Roluri_Nepermise reprezintă setul de roluri care nu pot executa ac țiunea a j
în M_M conform ma șinilor de stare;
– Roluri_Permise(r i) = ∪ { r i | must_do r (ri, aj) ∈ M_M}.
Roluri_Permise reprezintă setul de roluri care pot executa ac țiunea a j în
M_M conform ma șinilor de stare
– Utilizatori_Nepermi și (u i) = ∪ { ui | ui apar ține rolului ri ∧ cannot_do r
(r i, aj) ∈ M_M}. Utilizatori_Nepermi și reprezintă setul de utilizatori
apar ținând unor roluri care nu pot executa ac țiunea a j în M_M conform
ma șinilor de stare;
– Utilizatori_Permi și (u i) = ∪ { ui | ui apar ține rolului ri ∧ must_do r
(r i, aj) ∈ M_M }. Utilizatori_Permi și reprezintă setul de utilizatori
apar ținând unor roluri care pot executa ac țiunea a j în M_M conform
ma șinilor de stare.
Defini ția 31 (consisten ța constrângerilor) : Fie CM(M) constrângerile unui model
bazat pe ma șini de stare. CM(M) este consistent dac ă și numai dac ă sunt îndeplinite
urm ătoarele condi ții:
– panic ∉ CM(M);
– ∀ tm al M_M:
– Dacă Tranzi ții_Permise ( tm) ≠ ∅, atunci:
Tranzi ții_Permise ( tm) ∩ Tranzi ții_Nepermise ( tm) = ∅;
Tranzi ții_Permise ( tm) ⊆ { tm | tm ∈ TT};
– ∀ ri al M_M:
– Dacă Roluri_Permise ( ri) ≠ ∅, atunci:
Roluri_Permise ( ri) ∩ Roluri_Nepermise ( ri) = ∅;
Roluri_Permise ( ri) ⊆ { ri | ri ∈ RT};
– ∀ ui al M_M:
– Dacă Utilizatori_Permi și ( ui) ≠ ∅, atunci:
Utilizatori_Permi și ( ui) ∩ Utilizatori_Nepermi și ( ui) = ∅;
Utilizatori_Permi și (ui) ⊆ { ui | ui ∈ UT};
– ∀ ui, ri ai M_M:
– Dacă Utilizatori_Permi și ( ui) ≠ ∅ și Roluri_Permise ( ri) ≠ ∅, atunci:
∃ rj ∈ { RT i \ Roluri_Nepermise (r i)} pentru care
∃ uj ∈ { RT i \ Utilizatori_Nepermi și (u i)}.
68 3.10 Fazele specific ării modelului
In această sec țiune prezint pa șii în crearea modelului SCAR-ACE. Specificarea
schematică a acestor pa și este ilustrată în figura 18, fiecare pas fiind realizat de c ătre o
anumit ă componentă a sistemului de autorizare.
Primul pas, denumit analiză static ă determin ă partea static ă a constrângerilor
modelului și verifică consisten ța acestora în confomitate cu definitia 31 (vezi și
3.9.4). Dacă verificarea se soldeaz ă cu e șec pasul este reiterat și constrângerile sunt
modificate pân ă când se elimin ă inconsisten ța. Această fază este realizată de c ătre
administratorul sistemului de securitate.
Dacă această fază se finalizeaz ă cu succes se trece la urm ătorul pas de
verificare/actualizare prin care se realizeaz ă asignarea de ac țiuni la roluri, în func ție
de faza de analiz ă static ă. In aceast ă faz ă constrângerile se pot modifica astfel încât s ă
fie eliminate regulile redondante.
Faza de planificare prime ște la intrare constrângerile și generează la iesire
ma șina de stare pentru fiecare rol, prin ata șarea st ărilor, tranzițiilor și a evenimentelor.
Dacă acestea nu pot fi realizate se va sesiza administr atorul sistemului de securitate
pentru reanalizarea modelului.
Dac ă aceast ă faz ă se finalizeaz ă cu succes se ata șeaz ă interfe ței grafice partea
activ ă a ma șinii de stare respectiv se stabilesc meniurile și butoanele de comutare de
la o stare la alta.
In continuare se vor detaila fazele specific ării modelului și se vor exemplifica
pentru cazul descris în figura 17.
69
Figura 18. Fazele analizei de specificare a modelul ui
3.10.1 Faza de analiz ă static ă
In faza de analiz ă static ă se verifică consisten ța p ărții statice a modelului. Figura
19 ilustreaz ă intr ările și ie șirile acestei faze.
Algoritmul prime ște la intrare specificarea aplicatiei și constrângerile acesteia și
verifică consisten ța p ărții statice a modelului. In cazul unui e șec se returneaz ă
FALSE; în caz contrar se returneaz ă modelul static și seturile Roluri_Permise , Start
Specificarea
rolurilor Specificarea
constrângerilor
Analiza
statica
Verificare /
Actualizare
Roluri
actualizate Parame tri și tranzi ții
actualizate
Planificare
Ma șina de
stare
Rulare GUI
70 Roluri_Nepermise, Utilizatori_Permi și, Utilizatori_Nepermi și, Tranzi ții_Permise și
Tranzi ții_Nepermise .
Figura 19. Intr ările și iesirile fazei de analiz ă static ă
Exemplu:
Consider ăm exemplul din figura 17. Partea static ă a constrângerilor este
compus ă din tranzi țiile t 1–t9 și regulile de tipul CM (vezi 5.4.2). Seturile de ro luri,
utilizatori și tranzi ții pentru figura 17 determinate în faza de analiz ă static ă sunt:
– Roluri_Permise = {R_VIZITATOR};
– Utilizatori_Permi și = utilizatori în Roluri_Permise;
– Roluri_Nepermise = Utilizatori_Nepermi și = ∅;
– Tranzi ții_Permise = {t 1, t2, …, t 9} ;
– Tranzi ții_Nepermise = {t 10, t11, t12, t13 }.
Consisten ța p ărții statice a M_M poate fi verificat ă imediat prin urm ătoarele:
1) predicatul panic ∉ CM (M);
2) Tranzi ții_Permise (t i) ∩ Tranzi ții_Nepermise (t i) = ∅;
3) Roluri_Permise (r i) ∩ Roluri_Nepermise (r i) = ∅;
4) Utilizatori_Permi și (u i) ∩ Utilizatori_Nepermi și (u i) = ∅;
5) ∃ r ∈ RT care s ă realizeze fiecare tranzi ție t i.
3.10.2 Faza de verificare / actualizare
Scopul fazei de verificare este de a modifica speci fica țiile fazei de analiz ă
static ă pentru a eficientiza execu ția fazelor urm ătoare.
In cadrul fazei de verificare se determina rolurile permise care apar țin
modelului. Dac ă setul de Roluri_Permise nu este vid, toate rolurile care nu apar țin Algoritmul 1. Algoritmul analizei statice
INPUT: 1) Specificatia aplicatiei;
2) Constrângeri_statice.
OUTPUT: 1) FALSE dac ă Constrângeri_statice este inconsistent;
2) Daca Constrângeri_statice est e consistent;
a) Seturile de Roluri_Permise , Roluri_Nepermise,
Util izatori_Permi și, Utilizatori_Nepermi și
Tran zi ții_Permise, Tranzi ții_Nepermise;
b) Modelul p ărții statice a aplicatiei.
71 acestuia ( și prin urmare apar țin la Roluri_Nepermise ) pot fi eliminate din specifica ție
deoarece asignarea acestora ar viola constrângerile modelului. Dac ă setul de
Roluri_Permise este vid atunci ac țiunile din partea static ă nu pot fi executate de
niciunul dintre roluri deci trebuie revizuite.
In cadrul fazei de analiz ă static ă se examinează seturile de Tranzi ții_Permise și
Tranzi ții_Nepermise . Regulile care se aplic ă în faza de verificare/actualizare asupra
rolurilor se aplic ă și asupra tranzi țiilor. Astfel, dac ă setul de Tranzi ții_Permise nu este
nul se elimină din setul de tranzi ții toate cele care nu apar țin acestui set. Dac ă setul de
tranzi ții este nul, setul de opera ții asignat acestora î și pierde consisten ța, deci trebuie
revizuit.
Un exemplu în cazul de fa ță ar fi extinderea setului de Tranzi ții_Nepermise cu
toate acele tranzi ții ce nu pot fi executate pentru exemplul considera t în figura 17.
Intr ările/ie șirile fazei de verificare/actualizare sunt ilustrat e în figura 20. Astfel
se prime ște la intrare rezultatul fazei de analiz ă static ă iar la ie șire, în urma verific ării,
se actualizează seturile de roluri, utilizatori și tranzi ții. Tot ca și rezultat, în urma
analizării tranzi țiilor se determin ă elementele active și pasive ale interfe ței grafice
caracteristice atât st ărilor ma șinii de stare precum și parametrii tranzi țiilor.
Figura 20. Intr ările și iesirile fazei de verificare / actualizare
Pentru determinarea elementelor active și pasive ale interfe ței grafice
corespunz ătoare unei st ări se iau în considerare tranzi țiile posibile din fiecare stare în
parte și, pentru fiecare tranzi ție, se genereaz ă un element activ. Pentru informa țiile de
selectat și de trimis sistemului ca și parametri ai tranzi țiilor vor fi constituite
elementele pasive care sunt atribute ale obiectelor interfe ței grafice. Elementele active
și pasive determinate, specifice interfe ței grafice utilizator, sunt ata șate fiec ărei st ări
în mod consistent și neredondant. Algoritmul 2. Algoritmul fazei de verificare/actualizare
INPUT: 1) Modelul p ărții statice;
2) Seturile de Roluri_Permise , Roluri_Nepermise,
Utilizatori_Per mi și, Utilizatori_Nepermi și
Tranzi ții_Permise, Tranzi ții_Nepermise.
OUTPUT: 1) Seturile verificate/actualizate de:
Roluri_Permise , Roluri_Nepermise,
Utilizatori_Per mi și, Utilizatori_Nepermi și
Tranzi ții_Permise, Tranzi ții_Nepermise;
2) Elementele active și pasive ale interfe ței grafice corespunz ătoare
st ărilor ma șinii de stare.
3) Parametrii tranzi țiilor.
72 Pentru determinarea parametrilor fiec ărei tranzi ții se iau în considerare
elementele pasive (sau un subset al acestora).
Exemplu:
Pentru exemplul considerat în figura 17 setul de in trare al fazei de
verificare/actualizare este constituit din rezultat ele fazei de analiz ă static ă (vezi 5.5.1).
Setul de ie șire este alc ătuit din:
1) Roluri_Permise = {R_VIZITATOR, R_CUMPARATOR,
R_VANZATOR};
Roluri_Nepermise, Utilizatori_Permi și, Utilizatori_Nepermi și,
Tranzi ții_Permise rămân nemodificate ;
Tranzi ții_Nepermise poate fi extins ă cu CM 2,4 , CM 2,5 respectiv t 14 și
t15 .
2) Exemplificare elemente active și pasive pentru starea s 1:
Elemente active:
– element activ: un buton ce declan șează tranzi ția în s 2 prin
emiterea evenimentului EV_SET_ATRIB;
– element activ : un buton ce declan șează tranzi ția în s 3 prin
emiterea evenimentului EV_GET_OBJECT;
Elemente pasive:
– identificator obiect;
– atribute obiect;
– imagine obiect.
3.10.3 Faza de planificare
Această fază generează asign ările ac țiunilor la roluri și a utilizatorilor la roluri
astfel încât toate constrângerile asociate modelulu i s ă fie satisf ăcute. Această fază este
realizată înaintea execu ției aplica ției.
Dup ă ce rolurile private au fost determinate se realize az ă asignarea utilizatorilor
la acestea, pentru cele publice neputându-se face n ominalizarea.
Pentru asignarea tranzi țiilor la ac țiuni se consider ă fiecare opera ție și se
determin ă ac țiunile de realizat și setul de tranzi ții corespunz ător. De exemplu pentru
opera ția de inserare a unui produs în co șul de cump ărături ac țiunile de realizat sunt:
selectarea produsului și a atributelor acestuia și ad ăugarea acestuia în co ș. Exist ă o
singur ă tranzi ție necesar ă realiz ării opera ției și anume cea din starea definit ă prin
pagina în care este setul de produse în starea în c are co șul a mai primit un produs nou.
Ultima etapa a planific ării o constituie verificarea tranzi țiilor constituente ale
setului de constrângeri f ără executarea aplica ției.
Exemplu :
Pentru ca sistemul s ă poată comuta între st ări se execută tranzi ții și fiec ărei
tranzi ții îi corespunde cel putin o ac țiune care asigur ă trecerea în starea urm ătoare.
In faza de planificare se asigneaz ă fiec ărui rol st ările, respective tranzi țiile
caracteristice în func ție de ac țiunile de efectuat.
73 Algoritmul fazei de planificare:
INPUT:
1) CM(M);
2) Roluri_Permise, Utilizatori_Permi și, Tranzi ții_Permise.
OUTPUT:
1) Predicate de planificare;
2) Asignarea actiunilor la roluri;
3) Asignarea utilizatorilor la rolurile private;
4) Secven ța de tranzi ții;
5) Ac țiunile specifice fiec ărei tranzi ții.
Figura 21. Intr ările și ie șirile fazei de planificare
Pentru exemplul analizat (figura 17) consider ăm t 2 prin care se realizeaz ă
opera ția de selectare a obiectului 1. Ac țiunea de realizat poate fi identificat ă (de
exemplu) cu a 2 – selectare obiect – și are predicatul de planificare:
must_execute r (R_VIZITATOR, a 2)
Tranzi ția de executat are predicatul de planificare:
must_execute t(t 2, s1)
Verificarea constrângerilor legate de tranzi ția t2 se realizează prin:
check(t 2, s1, s2)
Rolurile care pot executa t 2 sunt urm ătoarele roluri publice (prin mo ștenirea de
la R_VIZITATOR): R_VIZITATOR, R_CUMPARATOR, R_VANZA TOR.
Pentru rolul de administrator si receptioner al une i cereri se nominalizeaza
utilizatorii.
3.10.4 Definirea ma șinii de stare
In această fază se realizează graful de apel, pentru fiecare rol pornindu-se de la
predicatele de planificare și de la secven ța de tranzi ții.
Datele de intrare și cele de ie șire sunt ilustrate în fig. 22.
Pentru exemplul din figura 17 datele de intrare sun t:
1) rolul R_VIZITATOR
2) tranzi țiile t 1– t 9
3) predicatele de planificare rezultate în faza anteri oar ă:
74 Algoritmul ma șinii de stare:
INPUT:
1) setul de roluri;
2) secven ța de tranzi ții;
3) predicate planificare.
OUTPUT:
1) G = (N,A) pentru fiecare rol.
Figura 22. Datele de intrare/ie șire ale ma șinii de stare
Datele de ie șire sunt constituite din ma șina de stare corespunz ătoare ilustrat ă în
figura 23.
Figura 23. Ma șina de stare pentru exemplul din figura 17
3.10.5 Interfa ța utilizator grafic ă
Dup ă realizarea fazei anterioare componen ța ma șinii de stare este adus ă într-o
stare func țional ă.
Faza curentă are drept scop realizarea interfe ței grafice cu utilizatorul pornind
de la masina de stare. Astfel, sunt definite pagini le utilizator care pot fi alc ătuite din
unul sau mai multe cadre. Fiec ărei scene îi este corespondent ă o stare în cadrul
ma șinii de stare. S1 S0
EV_START
S2
S3 S4
S5
S6 EV_SET_ATRIB EV_SET_ATRIB
EV_SET_ATRIB EV_SET_ATRIB
EV_GET_OBJECT
EV_GET_OBJECT
EV_COMPARE EV_COMPARE
75
Figura 24. Faza de realizare a interfe ței grafice cu utilizatorul
Pentru exemplul din figura 17 voi ilustra interfa ța grafic ă rezultat ă cu pagina
real ă din implementare:
3.10.6 Faza de rulare
Faza de rulare este realizat ă prin executarea ac țiunilor specifice tranzi țiilor
componente ale ma șinii de stare. La execu ția unei ac țiuni utilizatorul este verificat
dac ă are drepturile de autorizare necesare realiz ării acesteia.
Acest mecanism se realizeaz ă în dou ă etape corespunz ătoare autoriz ării:
– Autentificare; Algoritmul fazei de realizare a interfe ței
grafice cu utilizatorul:
INPUT:
1) G = (N, A) pentru fiecare rol.
OUTPUT:
Interfa ța grafic ă cu utilizatorul.
Figura 25. Interfa ța grafic ă pentru selectarea si compararea a dou ă obiecte
76 – controlul accesului.
Autentificarea este realizat ă de c ătre sistem și constă în verificarea numelui și
parolei furnizate de c ătre utilizator.
La execu ție utilizatorul urmeaz ă trasee în cadrul ma șinii de stare specifice
rolului pe care acesta îl posed ă ceea ce înseamn ă că întotdeauna se afl ă în una din
st ările definite ale lui G.
Dacă utilizatorul dore ște realizarea unei ac țiuni, acesta activeaz ă un element
activ al interfe ței grafice. Aceast ă ac țiune poate avea dou ă consecin țe:
(1) Dacă elementul activ este valid pentru acel utilizator, selec ția acestuia va
determina apari ția unui eveniment, declan șarea tranzi ției și, drept
consecin ță , realizarea ac țiunii cerute.
(2) Dacă elementul activ nu este valid nu se va declan șa un eveniment.
Similar, există și alte surse posibile de eroare precum existen ța st ărilor izolate
de sistem, sau încercarea realiz ării unei tranzi ții nepermise.
In cazul în care tranzi ția a fost executat ă cu succes se introduc reguli de tipul:
exec t (ri, tj, sk, e e, pn) /barb2left
și
succes (a j, sk, e e, pn) /barb2left
Dacă oricare dintre erori este semnalat ă în cadrul fazei de execu ție se introduc
predicate de tip abort și sistemul este modificat și trecut din nou în faza de
planificare pentru corectarea realiz ării acestuia. De notat c ă faza de planificare nu
trebuie reluată de la început ci poate fi invocat ă numai pentru acele tranzi ții care au
semnalat erori și doar în cazul cel mai defavorabil se va relua faz a de planificare de la
început. Acest algoritm este unul incremental pân ă la realizarea complet ă a aplica ției.
77 4 Analiza aplica țiilor de comer ț electronic și
implementarea modelului SCAR-ACE
Pentru validarea modelului SCAR-ACE s-a implementat o aplica ție distribuită
de comer ț electronic. Pentru aceasta s-a realizat preliminar analiza acestui tip de
aplica ții [O00].
4.1 Introducere
Termenul de comer ț electronic pe Internet desemnează utilizarea Internetului
pentru vânzarea și cump ărarea de bunuri și servicii, incluzând suport dup ă vânzare
[TS98]. Internetul poate fi un mecanism eficient pe ntru publicitate și distribuirea
informa țiilor despre produse dar scopul lui principal in ca zul aplicatiilor comerciale
sunt tranzac țiile de afaceri.
Comer țul pe Internet este unul dintre multiplele tipuri d e comer ț electronic iar
implementarea unei aplica ții de comer ț electronic se supune modelului propus
deoarece poate fi asimilat ă și tratată ca și o secvent ă dat ă de st ări și tranzi ții între st ări
pentru care sunt definite constrângeri.
Comer țul electronic are o istorie mai veche, și se refer ă la modul de a pune în
leg ătur ă furnizorii de bunuri cu cump ărătorii, incluzând utilizarea calculatoarelor și a
tehnologiilor de comunica ție în afaceri financiare, sisteme de rezervare a bi letelor de
avion, procesarea comenzilor, gestionarea inventare lor, etc.
In comer țul pe Internet comunicarea are loc într-o re țea publică partajat ă. Mai
important, Web-ul permite tranzac ții spontane între cump ărători și vânz ători f ără a
exista o rela ție anterioar ă între ace știa.
In primul rând, și cel mai important, comer țul pe Internet se refer ă la afaceri:
utilizarea efectiv ă a re țelelor pentru a ob ține scopul propus al afacerii.
Aplica țiile de comer ț pe Internet implica mai multe componente și tehnologii:
Web, baze de date, re țele de mare vitez ă, algoritmi de criptare, multimedia, etc.
Punerea acestora impreun ă pentru a forma un sistem securizat, de mare perfor man ță ,
poate fi o provocare. In timp, comer țul pe Internet a suferit modific ări diverse și a
crescut vertiginos în ultimii ani.
4.2 Lan țul valoric
Comer țul pe Internet se poate privi în termenii lan țului valoric necesar unei
afaceri. In parte, lan țul valoric este relativ la afacerea propriu-zis ă (de exemplu
vânzarea de c ărți). Pe de altă parte lan țul valoric se adreseaz ă realiz ării afacerii on
line. In țelegerea acestor dou ă p ărți (a afacerii propriu-zise si a afacerii on-line) și a
modului de îmbinare a acestora este un pas importan t în realizarea de aplica ții de
comer ț electronic pe Internet.
Componentele generale ale lan țului valoric sunt [M94]:
• Atragerea clien ților;
• Interac țiunea cu clien ții;
78 • Ac ționarea la instruc țiunile clientului;
• Reac ția la cererile clien ților.
Componentele cheie ale lan țului valoric pot fi foarte diferite pentru industri i
diferite, și chiar în cadrul aceleia și industrii, pentru afaceri diferite.
4.2.1 Atragerea clien ților
Prima component ă a lan țului valoric pentru o aplica ție generică de comerț
electronic este atragerea clien ților. Prin aceasta se în țeleg mijloacele utilizate de a
aduce un client nou, de a-l face interesat într-un site: prin reclama pe Web, mail
electronic, televiziune, afi șe sau alte forme de marketing [B06]. Scopul acestei faze
este trezirea interesului clien ților în a vedea cataloagele de produse sau a altor
informa ții despre produsele și serviciile propuse vânz ării.
4.2.2 Interac țiunea cu clien ții
A doua component ă este interac țiunea cu clien ții si se refer ă la comandarea
produselor. Aceast ă fază este în general orientat ă pe produs și include cataloage,
publica ții sau alte informa ții disponibile pe Internet. Con ținutul poate fi distribuit în
diferite forme precum WWW, po ștă electronic ă sau alte mijloace media precum CD-
ROM-uri.
Con ținutul se poate modifica mai rar sau frecvent. Tehn ic, con ținutul poate fi
static sau dinamic. Con ținutul static const ă din pagini preg ătite cum ar fi cele dintr-un
catalog care sunt trimise unui client la cerere. Ac este pagini se modific ă atunci când
se schimb ă informa ția con ținut ă pe acestea. Con ținutul dinamic este generat la
momentul emiterii unei cereri și este alc ătuit de la una sau mai multe surse pentru a
produce o pagin ă în conformitate cu cerin ța clientului. Sursele de creare a con ținutului
dinamic includ bazele de date, iar partea dinamic ă poate fi de exemplu pre țul unui
produs.
4.2.3 Ac ționarea la instruc țiunile clientului
Componenta urm ătoare este ac ționarea la instructiunile clientului. Odat ă ce un
cump ărător a c ăutat printr-un catalog și dore ște să cumpere un produs, trebuie s ă
existe o modalitate de a oferi acestuia posibilitat ea de a efectua o comand ă, s ă
proceseze plata și să se realizeze livrarea produsului. Componentele ace stei etape
constau din: procesarea comenzii, plata produselor și livrarea acestora [HH02].
Procesarea comenzii . Uneori cump ărătorul dore ște să cumpere mai multe
produse în acela și timp, a șadar procesarea comenzii trebuie s ă includ ă posibilitatea ca
mai multe entit ăți s ă poată fi grupate pentru cump ărarea ulterioar ă. Această facilitate
este denumită co șul de cump ărături pentru tranzac țiile cu de am ănuntul și, în mod
uzual, include posibilitatea de a- și modifica con ținutul în orice moment. Astfel,
cump ărătorul are facilitatea de a desc ărca entit ăți, de a ad ăuga unele noi sau s ă
modifice cantit ățile.
79 Plata . In func ție de termenii comenzii, cump ărătorul poate pl ăti odată ce
comanda este final ă. Ca și în via ța real ă există mai multe posibilit ăți de a pl ăti: car ți
de credit, ordine de plat ă, etc.
Livrarea . Pasul urm ător depinde de tipul item-urilor cump ărate. Dacă sistemul a
comandat un bun fizic acesta va fi livrat cump ărătorului. In acest caz sistemul trebuie
să aib ă un mijoc de plasare a comenzilor care s ă impacheteze bunul și s ă îl trimit ă.
Un alt tip de comand ă este unul pentru un serviciu care s ă fie executat în lumea
real ă. De exemplu cineva a comandat o telegram ă cânt ătoare online. Pentru realizarea
acestui serviciu se realizeaz ă un mecanism similar celui anterior și anume trebuie s ă
existe un departament c ătre care cererea s ă fie trimis ă spre procesare, departament
care va realiza serviciul cerut.
Un al treilea tip de item cerut este mai apropiat s istemului electronic și poart ă
denumirea de bun digital. Bunurile digitale includ o paletă larg ă de servicii cu
distribuire online, incluzând software, ziare sau a rticole de nout ăți, rapoarte, accesul
la baza de date pentru o anumit ă perioad ă de timp.
4.2.4 Reac ția la cererile clien ților
Dup ă ce vânzarea a fost complet ă clientul poate întâmpina dificult ăți sau s ă aib ă
întreb ări relativ la bunul achizi ționat care necesit ă service. Cele mai multe întreb ări
necesit ă o persoan ă care s ă raspund ă, la altele poate fi sistemul cel care r ăspunde.
4.3 Modele de afaceri
In func ție de cerin țele sistemului și a op țiunilor de design se pot enumera
urm ătoarele tipuri de segmente de afaceri [T05]:
• Retail sau Business-to-Consumer (B2C)
Afacerea prin care se vând bunuri direct unui consu mator final individual.
• Business-to-business (B2B)
Sunt afacerile cu cataloage de vânzare online prin care se comercializeaz ă
bunuri c ătre alte afaceri. In aceast ă categorie intr ă MRO (maintenace,
repair and operation) și COGS (cost of goods and services). COGS
implică comenzi mari pentru productie și tehnologii precum EDI și XML.
• Comer țul informa țional
Aceasta este o categorie larg ă si include afaceri care planific ă distribuirea
bunurilor digitale (produse informa ționale și servicii). Sunt incluse
publica țiile online și distribuirea de software online.
In sensul marketingului, un segment de afaceri este o colec ție de companii din
aceea și arie, cum ar fi produc ătorii de automobile, redactorii publica țiilor, care au
acelea și cerin țe pentru produse și servicii. Se utilizeaz ă denumirea de segment pentru
a descrie colec ții de afaceri cu cerin țe similare pentru comer țul pe Internet.
80 4.3.1 Similarit ăți și diferen țe la nivel de segment
Există mari similarit ăți în cerin țele celor trei segmente descrise [LL98]. Toate
trebuie s ă atrag ă clien ții, s ă prezinte produse, s ă asambleze comenzi, s ă realizeze
tranzac ții, și s ă distribuie bunurile comandate. Exist ă îns ă și diferen țe. Spre exemplu
segmentul de retail are mare nevoie de capabilit ăți de comercializare, în timp ce
aplicațiile business-to-business au cerin țe majore în sistemele de plat ă și pentru
aprobarea fluxului produc ției.
Sistemul de comercializare a informa țiilor este cel mai distinctiv dintre cele trei
deoarece bunurile digitale nu necesit ă distribu ție fizică a produselor și serviciul de
vânzare c ătre client (ca și celelalte), dar are mari necesit ăți de îndeplinire online.
4.3.2 Participan ți la sistem
Sistemele de comer ț pe Internet au mai multe tipuri de participan ți în func ție de
rolul și scopul acestora [PS05], [EE01].
Cump ărătorii cer un set de opera ții; designer-ii de cataloage, reprezentan ții
serviciilor client și operatorii de sistem fiecare are setul lui de cer in țe. Pentru anumite
afaceri, în mod particular pentru cele de dimensiun e redus ă, o persoan ă poate
îndeplini toate aceste sarcini. Pentru afacerile de amploare persoane diferite realizeaz ă
sarcini diferite. Considerarea separat ă a rolurilor permite satisfacerea cerin țelor unei
aplica ții de orice m ărime, permi țând unei afaceri de mic ă întindere s ă creasc ă f ără a
reconsidera rolurile persoanelor implicate în fieca re etap ă.
Discutând în termeni de roluri, acest lucru implic ă și eliminarea oric ărei
confuzii. De exemplu, simpla referire la un client nu distinge cazurile când o persoan ă
selecteaz ă un produs pentru a fi cump ărat și o alta care s ă realizeze plata. Prin
definirea opera țiilor unui rol particular se asigura c ă toate functionalitatile necesare
acelui rol sunt prezente în sistem.
Cump ărători . In context, cump ărător însemnă consumator. Este necesar ca un sistem
de comer ț s ă realizeze necesit ățile consumatorilor, dar diferite tipuri de cump ărători
necesit ă lucruri diferite, și interesele lor sunt uneori antagoniste celor ale vânz ătorilor.
Consumatorii se departajeaz ă în:
• consumatori retail – ace știa sunt consumatorii care utilizeaz ă sistemul
de comer ț B2C.
• consumatorii de business – sunt acei cump ărători care utilizeaz ă
sisteme de comer ț B2B.
Vânz ători . In context, termenul vânz ător include furnizorii angajati în sistemele B2C,
B2B sau furnizorii de publica ții și con ținut în sistemele de comer ț informa țional.
Procesoare financiare . Acestea opereaz ă partea de procesare a c ărților de credit care
acceptă tranzac ții de la furnizori și trimite datele necesare cumpararii (precum
numarul cartii de credit si data la care acesta exp ira) mai departe b ăncii furnizorilor.
Securitatea este cuvântul cheie pentru un procesor financiar. Securitatea include ca
înregistr ările s ă fie private și clare, și sa fie asigurate autenticitatea și integritatea
cererilor.
81 Tehnicieni . Tehnicienii au un rol major în crearea sistemelor de comer ț pe Internet.
Pentru a se expanda pia ța pentru comer țul pe Internet este necesar ă construirea
produselor în jurul unui nucleu tehnologic. Țelul tehnicienilor este acela de a construi
un sistem simplu și general care rezolv ă majoritatea problemelor.
In continuare se discut ă câteva roluri atât pentru cump ărător cât și pentru
vânz ător [FL00]:
Roluri client . In orice tranzac ție comercial ă exist ă un vânz ător și un cump ărător. Se
utilizeaz ă mai multe cuvinte pentru cump ărător: client, consumator, agent de
cump ărări, etc. Pe Internet se utilizeaz ă cuvintele client și browser cu acela și înteles,
cu referire mai mult la software decât la persoan ă. Dar exist ă diferen țe subtile între
aceste cuvinte și distinc ția reflect ă anumite roluri pe partea de cump ărător. In anumite
cazuri cum ar fi client de achizi țion ări, aceea și persoan ă joac ă mai multe roluri f ără
chiar a ne gândi la aceasta. Exist ă a șadar într-o afacere mai multe roluri:
• Specificator – aceast ă persoan ă selecteaz ă bunul de cump ărat;
• Intermediar – aceast ă persoan ă aprob ă bunul selectat de
specificator;
• Cump ărător – aceast ă persoan ă negociaz ă termenii și condițiile unei
achizi ții și specific ă plata;
• Recipient – aceast ă persoan ă prime ște produsul cump ărat.
In plus se pot distinge tipuri de cump ărători în func ție de rela ția acestora cu
furnizorul:
• Cump ărător anonim – nu are nici o rela ție cu vânz ătorul și poate să
nu creeze nici una la realizarea unei achizi ții;
• Client membru – sunt cei care cump ără în mod repetat de la un
vânz ător și au stabilit un soi de rela ție numit ă rela ție de membru.
Membrii se identific ă în sistem deoarece acesta le ofer ă anumite
beneficii.
Rela ția de membru d ă na ștere unui alt rol și anume administrator al membrului :
o persoan ă care ac ționeaz ă în acest rol și poate modifica sau actualiza orice informa ție
de profil memorat ă despre membru. Dac ă rela ția de membru cuprinde câteva conturi
individuale, ca cele pentru o familie de membri sau agen ți multipli, administratorul
poate seta limit ări în utilizarea conturilor individuale. Aceste lim it ări pot fi de genul:
tipurile de produse de cump ărat, cantitatea acestora, timpul zilei pentru cump ărături,
etc.
Aceasta ne spune c ă un sistem de comer ț pe Internet necesit ă o modalitate prin
care diferi ți oameni pot modela diferite p ărți ale unei tranzac ții, și cum o singur ă
persoan ă poate mânui toate aceste roluri. Consumatorii nu p resupun a-și schimba rolul
foarte des și în mod explicit la fiecare faz ă dar se așteapt ă să aib ă un proces ușor de
realizare a cump ărăturii. Companiile, pe de alt ă parte, cele care fac distinc ție între
roluri diferite doresc s ă gestioneze tranzac țiile dintr-un rol în altul în mod facil și
eficient.
Rolurile furnizorului . De partea cealalt ă a unei tranzac ții este vânz ătorul. Exist ă
diferite roluri într-un sistem de comer ț electronic pentru furnizori. Determinarea
tuturor rolurilor la început face posibil ca afacer ea pe Internet s ă creasc ă într-un mod
facil pe m ăsur ă ce mai multe persoane se raliaz ă echipei și rolurile devin mult mai
distincte. Pentru vânz ător exist ă dou ă grupe principale de roluri: rolurile afacerii și
con ținutului și rolurile echipei opera ționale.
82 Rolurile urm ătoare sunt cele mai importante roluri ale afacerii:
• Manager afacere: Responsabil cu abordarea afacerii relativ la Internet,
crearea și operarea în prezen ța Internetului – decide care produse și servicii
urmeaz ă a fi comercializate si determin ă pre țurile;
• Arhitectul de comer ț pe Internet: Este un analist de sistem care transf orm ă
cererile afacerii în design sistem; acesta creaza și gestioneaza con ținutul
(cataloagele), proceseaza tranzac țiile, se ocupa de aspectele tehnice ale
seviciului clien ți;
• Designer de con ținut: Este responsabil cu imaginea sistemului de co mer ț
pe Internet incluzând designul grafic;
• Autor de con ținut: Creaz ă și adapteaz ă informa țiile despre produse într-o
form ă care poate fi utilizat ă în comer țul pe Internet;
• Implementator: Creaz ă programele software necesare func țion ării
sistemului.
• Administratorul bazei de date: Gestioneaz ă crearea și operarea bazei de
date pentru a-i asigura corectitudinea, integritate a și performan ța;
• Serviciul vânz ări și marketing: Responsabil cu promovarea sistemului d e
comer ț bazat pe Internet pentru afacere;
• Serviciul clien ți: R ăspunde la întreb ările despre produse, asist ă
cump ărătorii în procesul de achizi ție, gestioneaz ă returnarea produselor.
Rolurile opera ționale sunt urm ătoarele:
• Manager opera ții: Responsabil cu gestionarea activit ăților pentru sistemul
de comer ț electronic;
• Supervizor sistem: Gestioneaz ă sistemul;
• Administrator sistem: Responsabil cu opera țiunile tehnice ale sistemului
de calculatoare și ale re țelei;
• Ofi țer de securitate: Asigur ă c ă s-au luat m ăsuri adecvate de securitate în
designul și implementarea sistemului de comer ț pe Internet;
• Agent vânz ări: Responsabil cu împachetarea și trimiterea bunurilor sau cu
serviciul de distribuire;
• Contabil: Responsabil cu serviciul de contabilitate care este asociat
sistemului de comer ț pe Internet.
4.4 Asigurarea intimit ății clientilor
4.4.1 Platforme pentru preferin ța intimit ății
Consor țiul WWW a lansat un grup de lucru denumit Platforma pentru
preferin țele intimit ății (Platform for Privacy Preferences – http://www.w 3.org.P3P/).
Pagina Web a acestui grup specific ă urm ătoarele [HTTP 103]:
"Proiectul preferin țelelor de intimitate (P3) va rezulta în specificare a și
demonstrarea unui mod interactiv de exprimare a pra cticilor și preferin țelor de
intimitate a site-urilor Web și respectiv a utilizatorilor acestora."
83 Un num ăr de organiza ții incluzând Netscape, Microsoft, Firefly și Verisign
cooperează în cadrul efortului W3 pentru specificarea intimit atii, utilizând Open
Profiling Standard al Firefly ca și punct de pornire. Asigurarea intimitatii clientil or
impune ca oricând un site cere informa ții personale sau de profil ale unui utilizator,
acestea pot fi furnizate automat, atâta timp cât in ten țiile declarate ale site-ului în
utilizarea acestor informa ții sunt conforme cu preferin țele utilizatorului.
4.4.2 Cookies
O tehnologie dezb ătută în asigurarea intimit ății utilizatorilor sunt cookies [L05].
Acestea sunt o inova ție ad ăugat ă browserelor de Web în 1995. In 1996 utilizarea
cookies-urilor a determinat discu ții controversate relativ la implica țiile lor în
intimitatea utilizatorilor.
Cookie-urile sunt o tehnologie care a transformat h it-urile Web f ără stare în
sesiuni pentru recunoa șterea automată a unui browser particular când se revine la un
site dup ă un anumit interval de timp, și pentru memorarea informa țiilor de profil ale
utilizatorului în cadrul browserului.
Cookies-urile sunt un protocol Web și un mecanism de browser care permit
unui server s ă spună unui navigator Web s ă memoreze un bloc de informa ție pe hard-
diskul utilizatorului, informa ție pe care s ă o trimită înapoi serverului la vizit ări
subsecvente. Cookies-urile furnizeaz ă suportul pentru sesiuni, recunoa șterea automată
a unui utilizator și memorarea profilului unui utilizator.
Există anumite avantaje dar și dezavantaje a cookies-urilor. Avantajele ar fi
urm ătoarele [PS00]:
Sesiunile . F ără sesiuni este imposibila furnizarea unui serviciu b azat pe Web care s ă
aib ă mai mult de un form. Dac ă este necesar ă o succesiune de formuri, acestea se
păstreaza pentru determinarea secventei de acces.
Recunoa șterea automată a unui utilizator . Identificarea automat ă a unui utilizator
particular este important ă pentru un serviciu de securitate care necesit ă autentificarea
și pentru oferirea unui serviciu care ofer ă vederi personalizate a utilizatorilor.
Profiluri ale clien ților . O aplicabilitate a cookies-urilor este c ă acestea asigur ă un loc
de plasare a anumitor informatii precum profilul ut ilizatorului sau starea aplica ției. Un
beneficiu al acestora este c ă serviciul nu sufer ă în performan ță în accesul la bazele de
date ale serverului pentru fiecare hit.
Cookies-urile îns ă prezintă și dezavantaje:
Trasare necunoscut ă. Cookies-urile pot fi folosite în site-urile Web p entru a memora
informa ții personale f ără acordul persoanei în cauz ă. Deoarece un cooky traseaz ă un
anumit browser, un site Web poate ob ține informa ții cu acurate țe la vizite repetate.
Dar informa țiile pot fi și f ără acurate țe, în mod particular dac ă un calculator este
partajat de mai mult de o persoan ă. Aceasta permite ca informa țiile despre o persoan ă
să fie ar ătate alteia.
84 4.4.3 Tranzac ții electronice securizate
In 1995 Visa și MasterCard și-au unit for țele pentru a dezvolta protocolul SET
(Secure Electronic Transaction), un standard tehnic pentru plata securizat ă cu carduri
pe rețele deschise.
SET este desemnat s ă mimeze fluen ța informatiilor unui card. In plus fa ță de
mesajele opera ționale, SET include utilizarea cheilor publice pent ru certificate pentru
a autentifica clientul si serverul unul fata de alt ul [RK00].
4.5 Arhitecturi func ționale ale aplica țiilor de comer ț electronic
Defini ția 32: Arhitectura unui sistem define ște componentele sale de baz ă și
conceptele importante și descrie rela ția dintre acestea [HBP +99].
Există mai multe c ăi de abordare a sistemelor de comer ț pe Internet, de la
simplu la complex. In parte, arhitectura depinde de natura afacerii, iar arhitectura
sistem dezvoltat ă pentru un B2C poate fi foarte diferit ă de cea a unui sistem
informa țional. Se crede c ă mai multe idei de design acoper ă un domeniu larg de cereri
de comer ț și c ă similarit ățile în sistemele pentru comer țul pe Internet sunt mai mari
decât diferen țele.
Arhitectura poate fi reutilizata ori de câte ori es te posibil. Mai important este c ă,
cu cât afacerea ajunge la un rafinament mai mare și î și expune țelurile pentru comer țul
pe Internet, cu atât va evolua și sistemul. Evolu ția poate merge dincolo de cerin țele
originale pentru sistem, astfel încât flexibilitate a arhitecturii este important ă în
posibilitatea cre șterii sistemului.
4.5.1 Idei arhitecturale de baz ă
Arhitecturile pentru comer țul pe Internet pot ar ăta foarte diferit, dar ele toate
adresează anumite rezultate și furnizează răspunsuri la un set comun de întreb ări.
Aceste rezultate trebuie în țelese foarte bine f ără a conta abordarea care se ia în
considerare. In anumite cazuri aceste întreb ări comune sunt considerate explicite pe
parcursul fazei de design; în alte cazuri întreb ările și răspunsurile la acestea se reflect ă
în presupuneri relativ la anumite componente arhite cturale [O00].
In țelegerea rolurilor . Dou ă dintre întrebarile de baz ă sunt "Cine utilizeaz ă sistemul?"
și "Ce se face în sistem?". Pentru anumite programe există câteva tipuri de utilizatori
care partajează țeluri similare.
Decompozi ția func țiilor . A doua parte important ă în arhitectur ă este modul în care
sistemul este descompus în unit ăți func ționale. Specificarea acestor unit ăți func ționale
și a interfe țelor dintre ele define ște arhitectura sistemului. Una din diferen țele dintre
arhitecturi este adesea modul în care ele grupeaz ă func țiile în unit ăți.
Legarea con ținutului la tranzac ții . Primele dou ă considera ții pentru arhitectura
sistemului, rolurile și decompozi ția, se aplică design-ului sistemelor. A treia parte a
arhitecturii sistem a aplica țiilor de comer ț electronic pe Internet este modul în care
con ținutul, precum cataloagele, este legat de procesare a tranzac țiilor. Într-un sistem
85 bazat pe hârtie, un cump ărător transcrie pe un ordin de plat ă num ărul entit ăților și
cantit ățile. Acestea se fac îns ă electronic într-un sistem de e-commerce.
Există câteva intrebari care necesita raspuns relativ la aplicatia de comert
electronic și anume:
• Cum realizează utilizatorul tranzac ția?
In majoritatea cazurilor utilizatorul vede un buton pe care scrie "Ap ăsa ți
aici pentru a cump ăra" sau poate ad ăuga entit ăți într-un co ș de
cump ărături pentru achizi ția lor ulterioar ă. Tranzac ția are loc fie pe buton
fie la cump ărarea final ă pentru co șul de cump ărături.
• Cum este verificat ă informa ția ?
In func ție de tehnologia utilizat ă, poate fi necesar ca sistemul
tranzac țional s ă verifice c ă informa ția legată de cump ărături (pre ț,
identificarea entit ăților cump ărate, etc) nu a fost modificat ă când a fost
trimis ă pe re țea. Deoarece Web-ul utilizeaz ă un protocol f ără men ținerea
st ării, sistemele pe Internet trebuie s ă-și verifice singure starea. Cu alte
cuvinte serverul trebuie s ă realizeze controlul accesului.
• Cum este potrivit ă informa ția ?
Anumite sisteme de comer ț pe Internet asigur ă o verificare în timp real
pentru a asigura cump ărătorii c ă produsele achizi ționate se afl ă pe stoc.
Dacă un produs este pe stoc, pân ă când este valabil acesta? Dac ă un
utilizator pune un produs în co șul de cump ărături pentru achizi ționarea
acestuia peste un interval de timp, sistemul promit e c ă acesta va fi
disponibil și în momentul realiz ării cump ărării?
Răspunsurile la aceste întrebari ajut ă la decizia pentru design-ul sistemului de
achizi ții prin Internet. Deoarece r ăspunsuri diferite pot determina design-uri diferite ,
este important ca r ăspunsurile s ă fie cunoscute înaintea design-ului.
4.5.2 Modele de încredere
In orice sistem distribuit, diferite componente au încredere una în cealalt ă
pentru una sau mai multe sarcini. Anumite component e pot avea încredere în altele
pentru orice tip de tranzac ție în timp ce alte componente nu accept ă nici un tip de
acces la distan ță . Specificarea acestor rela ții între componente este denumit ă modelul
de încredere (trust model) pentru sistem [YD05]. Orice model are cel pu țin un sistem
de încredere, iar specificarea lui explicit ă ajută la în țelegerea rela țiilor dintre
componente atunci când este necesar ă analiza securit ății sistemului.
4.5.3 Arhitecturi sistem
Se prezintă trei arhitecturi posibile [FSN05] și arhitectura modelului SCAR-
ACE si se discut ă modul în care au fost construite. Cele patru arhit ecturi sunt:
1 un server Web cu formuri de comenzi;
2 o varia ție a unui sistem Web cu formuri de comenzi care uti lizează
protocolul SET;
3 un sistem de tranzac ții distribuite dezvoltat pentru Open Market;
4 arhitectura SCAR-ACE de B2B.
Există bineînțeles și alte abord ări ale comer țului electronic.
86 Pentru analizarea arhitecturilor s-au considerat pa tru componente sistem:
• Cump ărătorul (clientul): este un calculator conectat la In ternet prin
intermediul unui furnizor de servicii Internet sau prin intermediul unei
rețele a corpora ției. Cump ărătorul utilizează acest calculator client pentru
a naviga și a realiza achizi ții.
• Vânz ătorul (furnizorul): Sistemul sau sistemele de calcu latoare
con ținând cataloagele furnizorului.
• Sistemul de tranzac ție: Sistemul de calculatoare care proceseaz ă o
comand ă particular ă și care sunt responsabile pentru plata, p ăstrarea
înregistr ărilor și alte aspecte ale afacerii relativ la tranzac ții.
• Gateway-ul de plat ă: Sistemul de calculatoare care ruteaz ă
instruc țiunile de plată către re țele financiare cum ar fi cele de autorizare a
cărților de credit.
Arhitecturi diferite utilizeaz ă aceste patru componente în moduri diferite. In
anumite sisteme câteva dintre aceste componente pot fi combinate pe un singur sistem
de calculatoare sau ca și sisteme separate.
Odată ce designerii sistemului de comer ț au selectat o diviziune de func ții există
încă o sumedenie de decizii de luat la nivel de func ționalitate. De exemplu func țiile
agregate care permit asamblarea entit ăților individuale într-o comand ă complet ă.
Arhitectura 1 : Server de Web cu formuri de comenzi
Un server Web cu pagini de catalog și un form de comand ă este construc ția cea mai
simpl ă a unui sistem de comer ț pe Internet. Acest server este adeseori denumit se rver
furnizor.
In acest exemplu, un singur server Web furnizeaz ă atât catalogul cât și
comenzile. Cu alte cuvinte serverul furnizor și serverul de tranzac ții sunt combinate
într-un singur sistem și nu exist ă nici un gateway de plat ă. Catalogul poate consta
dintr-un set de pagini Web care descriu entit ățile de vândut, încapsulând imagini,
specifica ții, anima ții, clipuri video sau audio, și altele. Paginile Web pot fi create ca și
ni ște pagini statice utilizând un editor HTML, sau pot fi create dinamic din baza de
date care con ține produsele și informa țiile descriptive ale acestora. Pentru fiecare
produs exist ă un buton care permite cump ărătorului achizitia acelui produs sau
adaugarea sa la co șului de cump ărături. Când cump ărătorul dore ște s ă achizitioneze
produsele, ac ționeaz ă asupra butonului de verificare și procesul pl ății demareaz ă ca și
parte a tranzac ției.
87
Figura 26. Arhitectura 1: Vedere fizic ă
Plata prin utilizarea cardurilor este cea mai uzual ă în zilele noastre pentru
tranzac ții client. Un form simplu de comenzi poate con ține entit ățile cump ărate, un set
de câmpuri pentru editarea informa țiilor despre card și adresa de livrat bunurile fizice.
Figura 27. Arhitectura 1: Vedere logic ă
Este posibil de asemenea ca serviciul Web s ă includ ă un mecanism diferit de
cump ărare. In versiunea cea mai simpl ă a acestui model, clientul Web nu are
capabilit ăți speciale pentru comer ț, a șadar aplica ția de comer ț nu necesit ă mecanisme
software adi ționale de plat ă. C ărțile de credit, ordinele de plat ă sau alte tipuri de pl ăți
pot fi utilizate în astfel de sisteme ținându-se cont de capabilit ățile de securitate de
ast ăzi ale Web-ului.
Arhitectura aceasta poate fi potrivit ă și suficientă pentru anumite tipuri de
aplica ții de comer ț. Caracteristica sa de baz ă este simplitatea. Pe de alt ă parte este
dificil de expandat pe m ăsur ă ce afacerea cre ște sau încorporeaz ă noi tehnologii și
componente.
Catalog și baza de
date de comenzi Cump ărător
cu browser
Retea
financiara Server furnizor
Internet
Catalog Comenzi
Server Web Generator pagini
catalog Generato r con ținut
static Formuri de
capturare
comenzi Cărți de
credit
88 Arhitectura 2: Arhitectura SET
SET este un standard pentru tranzac țiile de plată cu c ărți de credit, care se
efectuează pe Internet. Într-un sistem cu SET, poarta de acce s pentru pl ăți este
ad ăugată distinct serverului de tranzac ții.
Diferen ța între un server Web cu formuri de comenzi și un sistem bazat pe SET
constă în modul în care formurile de comenzi sunt gestion ate și în modul în care este
realizat ă comunica ția pentru efectuarea pl ății [BHM06].
Figura 28. Arhitectura SET
In forma sa cea mai simpl ă, arhitectura SET comunic ă de la serverul furnizor
pân ă la poarta de acces pentru efectuarea pl ăților. Serverul furnizor, nu se conecteaz ă
direct la o re țea autorizată în plata cu c ărți de credit ci încorporeaz ă un modul SET.
Când modulul SET este apelat pentru a se realiza o plată au loc urm ătoarele ac țiuni
[TT02], [BPM02]:
• Modulul furnizor trimite un mesaj c ătre buzunarul SET care este pe
calculatorul cump ărătorului, con ținând o descriere a comenzii și a pre țului
total.
• Cump ărătorul utilizează buzunarul SET pentru a selecta un mod de
plată și a aproba plata.
• Buzunarul SET comunic ă, via calculatorul furnizor, cu poarta de acces
SET pentru efectuarea pl ății la banca cerut ă de furnizor.
• Poarta de acces se conecteaz ă la o re țea financiar ă tradi țional ă pentru a
autoriza tranzac ția.
• Calculatorul furnizor memoreaz ă aprobarea și trimite o confirmare de
primire cump ărătorului.
89 Arhitectura 3: Arhitectura Open Market Commerce
Ideea acestei arhitecturi este separarea gestion ării con ținutului de gestionarea
tranzac țiilor printr-o tehnologie denumit ă SecureLink . Această idee permite serverelor
multiple de cataloage s ă partajeze capacitatea unui singur motor de tranzac ții și
permite p ărților orientate pe con ținut ale sistemului, s ă se scaleze în mod independent
fata de p ărțile orientate pe tranzac ții ale sistemului. Figura 29 arat ă arhitectura fizic ă
[SL98], [DK01], [C03]. In aceast ă arhitectur ă, serverul de tranzac ții este separat de
serverul furnizor și poate s ă existe sau poate s ă nu existe o poart ă separată de plată
depinzând de metodele de plat ă suportate.
Figura 29. Arhitectura fizic ă cu SecureLink
4.6 Implementarea modelului SCAR-ACE
4.6.1 Prezentarea arhitecturii
Arhitectura se adreseaz ă aplica țiilor de B2B [OG05] în care sunt implicate
diverse grupe de actori. Ideea de baz ă a acestei arhitecturi este separarea
func ționalit ății de comer ț între partea orientat ă pe cump ărare și cea orientată spre
vânzare astfel încât fiecare organiza ție s ă isi gestioneze activit ățile specifice (figura
31).
Acest design este bazat pe modelul afacerii aratat mai jos:
Figura 30. Procesul de achizi ție Server de
tranzac ții
partajat Servere cu
cataloage
SecureLink
Internet
Retea
financiara
Navigare Cerere Aprobare Primire Completare Plat ă
90 In acest model logica de separare a activit ăților este astfel: procesele de
navigare și cerere sunt pe partea de cump ărător iar catalogul, gestionarea comenzilor,
completarea și plata sunt pe partea de furnizor. Aceast ă arhitectur ă rezultă în
arhitectura logic ă ilustrată în figura 32. Idea este divizarea serverului de tr anzac ții în
parte de cump ărător și parte de vânz ător.
Pentru ca aceast ă arhitectur ă să fie func țional ă sunt necesare dou ă elemente de
interoperabilitate între partea cump ărătoare și partea furnizoare: autentificarea
clientului și gestionarea comenzilor.
Figura 32. Arhitectura logic ă
• Autentificarea clientului Acest model utilizeaz ă autentificarea prin nume
utilizator și parol ă. Client Furnizor Navigare catalog/cump ărare
Interogare stare comand ă
Organiza ție
cump ărătoare Informa ții profil
Comenzi
Vederi/Actualiz ări
Autoritate
de plat ă Validare plat ă Creare comand ă
& aprobare Vehicul de plat ă
Autorizare
Servere
cump ărător Servere
furnizor
Poarta de
acces
Cump ărător
cu browser Internet
Retea
financiara
Figura 31. Arhitectura fizic ă
91 • Gestionarea comenzilor – în cadrul acestui model, clientul creaz ă o
comand ă prin interac țiunea cu catalogul furnizorului. Aceast ă comand ă
este trimis ă unui format standard denumit Cerere comand ă de pe serverul
furnizorului pe serverul cump ărătorului. Odată ajuns ă acolo, toate
aprob ările necesare sunt procesate. Dup ă finalizarea comenzii, aceasta este
returnată furnizorului ca și comanda ferma.
4.6.2 Fluen ța tranzițiilor
Pentru a realiza un proces de achizi ție sistemul realizeaz ă urm ătorii pa și:
1. Clientul folose ște un navigator Web și accesează sistemul. Nivelul de
autorizare ini țial este minim și anume rolul s ău este cel de vizitator ;
2. Serverul cu catalogul organiza ției furnizoare autentific ă clientul și îi permite
acestuia să navigheze și să selecteze articole. Dup ă autentificare clientul
trece în rolul de cump ărător;
3. Cump ărătorul mapează comanda într-o cerere, o încapsuleaz ă într-un obiect
și transmite cererea de comand ă organiza ției furnizoare utilizând Internetul;
4. Clientul specific ă orice adnot ări necesare comenzii și furnizorul realizeaz ă
aprobarea intern ă;
5. Organiza ția furnizoare începe distribuirea comenzii.
4.6.3 Func ționalit ăți implementate
Vizitatorul este utilizatorul cu nivelul de securit ate cel mai sc ăzut și orice
încercare de acces a unui utilizator îl direc ționeaz ă pe acesta spre pagina de “Home”
aceasta fiind prima func ționalitate implementat ă. Din aceast ă pagin ă utilizatorul poate
vizualiza catalogul de produse, poate intra pe pagi na de comparare a produselor sau se
poate autentifica în sistem prin login sau înregist rare.
In cadrul catalogului de produse se pot vizualiza p rodusele în func ție de anumite
criterii: produse de acela și tip, produse ale unui furnizor sau cele care au o anumit ă
caracteristic ă selectat ă.
Mecanismul implementat în pagina de comparare a pro duselor este cel descris
în figura 17.
Aceste func ționalit ăți sunt mo ștenite de rolurile de cump ărător și de vânz ător.
Un utilizator are rolul de cump ărătorul dup ă înregistrare, și î și poate modifica
informa țiile de identificare de pe pagina cu profilul s ău. Aceast ă pagin ă con ține date
de identificare gen nume și adresa precum și informa țiir pentru care ar dori notific ări.
Totodat ă cump ărătorul poate selecta produse în co ș și poate emite cereri de
livrare. Chiar dac ă au fost selectate unul sau mai multe produse pentr u achizi ționare,
acestea pot r ămâne în co ș f ără a se materializa într-o cerere ferm ă. Informa țiile
acestea precum co șul de cump ărături și cererile ferme sunt p ăstrate persistent în baza
de date și pot fi accesate în orice sesiune dup ă autentificare.
Cump ărătorul mai mo ștene ște și toate func ționalit ățile oferite vizitatorului.
4.6.4 Platforma de comer ț electronic
Această sec țiune descrie platforma de gestionare a tranzi țiilor și legarea
automată a obiectelor în arhitecturile de comer ț electronic. Aceast ă platform ă a fost
programat ă utilizând tehnologia Microsoft COM/DCOM. Sistem de serve ște mai mul ți
92 clien ți și mai multe tipuri de actori. Orice tranzi ție între dou ă st ări diferite, bine
definite, trebuie gestionat ă de c ătre aplica ția server în momentul rul ării ca rezultat a
informa țiilor parametrizate trimise de c ătre client. In ciuda faptului c ă selectarea
dinamic ă induce costuri la rulare, flexibilitatea rezultat ă permite prototipizarea rapid ă
a aplica ției și reduce timpul de dezvoltare a acesteia. Nucleul a rhitecturii este alc ătuit
din ma șini de stare care încapsuleaz ă mecanismul de control al accesului bazat pe
roluri în care sunt controlate tranzi țiile între st ări.
Un pas important în designul unui sistem de e-comme rce, bazat pe un mecanism
de control al accesului este în țelegerea rolurilor client. Aceasta ajut ă la concentrarea
aten ției asupra faptului ca fiecare persoan ă să utilizeze sistemul în îndeplinirea
scopurilor propuse, fie c ă aceasta este realizarea unei cump ărături sau ob ținerea unor
rapoarte.
Pe de altă parte, orice decizie în designul atât a program ării bazate pe obiecte
cât și a mediului trebuie s ă se confrunte cu alegerea între static și dinamic.
Propriet ățile statice se refer ă la alegerile realizate în momentul dezvolt ării, înaintea
execu ției programului în timp ce aspectele dinamice depin d de op țiunile și alegerile
care sunt validate doar în momentul rul ării aplica ției.
Implementarea sistemului SCAR-ACE implic ă cerin țe dinamice legate de
controlul accesului, fluen ța controlului aplica ției, astfel încât orice tranzi ție între dou ă
st ări este determinat ă la rulare și este executată conform parametrilor de transfer între
dou ă st ări. Dacă parametrii sunt gre șiți și nu potrivesc unei st ări consecvente atunci
este emisa o excep ție.
4.6.5 Structura aplica ției. Nivelele prezentare și de control al fluen ței
Aceast ă sec țiune descrie nivelul de prezentare (Presentation La yer – PL) și cel
de control al fluen ței aplica ției (Workflow Layer – WFL), tipurile de clien ți,
descrierea interfe ței între aplica ție și navigatoare și a interfe ței dintre WFL și nivelul
de logic ă a aplica ției (Business Logic Layer – BLL). Figura 33 ilustre az ă nivelele
aplica ției.
93
Figura 33. Structura pe nivele a aplica ției
Nivelul prezentare – PL
Clien ții accepta ți de aplica ție sunt cei XML și DHTML. Tehnologiile utilizate
pe partea de client sunt DHTML, Java Script și CSS.
Paginile HTML con țin câmpuri ascunse cu date pentru nivelul de contro l al
fluentei aplicatiei. Câmpurile ascunse sunt declara te în cadrul formurilor, care au
aceea și structur ă pe fiecare pagin ă client:
<form name="actionForm">
<input name="EK_CS" type="hidden">
<input name="Event" type="hidden" value="" />
<input name="Param1" type="hidden" value="END" />
…
<input name="Param8" type="hidden" value="END" />
</form>
Semnifica ția variabilelor este dup ă cum urmeaz ă: Client 1
Navigatoare XML
Format: XML + XSL =
(D)HTML Client 2
Navigator DHTML
Componenta WFL
Nivelul de logic ă al aplica ției (BLL)
Nivelul de acces la date (DAL)
Sursa de date Internet
Formatare:
XML + XSL = DHTML
94 • EK_CS – con ține concatenarea urm ătoarelor date: rolul
utilizatorului și identificatorul utilizatorului. Rolul utilizatoru lui
este un caracter ce poate lua diferite valori (în a cest exemplu v –
rol de vizitator) și desemneaz ă rolul utilizatorului în cadrul
aplica ției. Identificatorul utilizatorului este o valoare unică care
identifică clientul în cadrul unei sesiuni. Aceast ă cheie este
generată dinamic de c ătre server;
• Event – reprezintă evenimentul emis drept rezultat al ac țiunii
utilizator la selectarea unui element activ al inte rfe ței grafice.
Această valoare este o constant ă actualizată pe partea de client;
• Param1, …, Param8 – reprezintă parametrii dependen ți de
selec ția utilizator în cadrul paginii curente. Valorile a cestora sunt
actualizate pe partea de client.
Nivelul de control al fluen ței aplica ției (WFL)
Nivelul de control al fluen ței aplica ției are rolul de a verifica consistenta si
corectitudine tranzitiilor din sistem. El implement eaza componentele TT din M_M
respectiv atat partea constanta cat si cea variabil a a tranzitiilor modelului.
Nivelul de control al fluentei aplicatiei const ă dintr-un fi șier script și o
component ă care rulează ambele pe server si furnizeaz ă interfa ța dintre nivelul
prezentare (clientul Web) și nivelul de logic ă al aplica ției.
Interfa ța cu nivelul prezentare este gestionat ă de componenta WFL iar secven ța
evenimentelor este urm ătoarea:
• nivelul prezentare declan șeaz ă cererea client;
• se crează o instan ță a componentei de control a fluentei careia i se tr imite
cererea client;
• se trimit parametrii client nivelului de logic ă al aplica ției;
• se ob ține r ăspunsul de la nivelul de logic ă al aplica ției și se trimite înapoi
clientului.
Comunicarea între nivelul de control al fluen ței aplica ției și nivelul de
prezentare este bidirec țional ă, dup ă cum se arată în figura urm ătoare:
95
Figura 34. Comunicarea utilizator – componenta de c ontrol a fluentei
Comunicarea Client – componenta de control a fluent ei
Cererea trimis ă de c ătre nivelul prezentare con ține parametrii care sunt inclu și
în câmpuri ascunse ale paginii HTML. Parametrii sun t trimi și paginii utilizând metoda
HTTP POST. Mai apoi ace ști parametri sunt converti ți în structura de mesaj și sunt
trimi și prin intermediul nivelului de control al fluentei catre componenta
corespunz ătoare din nivelul de logica al aplicatiei.
Exemplificare:
Presupunem c ă utilizatorul selecteaz ă o entitate de pe pagina de cump ărare și
ac ționează Print Preview . Parametrii trimi și c ătre nivelul de control al fluentei
aplicatiei sunt:
EK_CS = c19efafa8-3634-11d4-a99d-
00d0b7151d330030
Stare = 2 (ST_CUMP_VIEW)
Event = 31 (EV_CUMP_PRINT_PREVIEW)
Param2 = BMS71
Param3 = END
unde:
• c din EK_CS – rolul utilizatorului care este de rolul de cumpa rato;r
• 19efafa8-3634-11d4-a99d-00d0b7151d330030 –
identificator utilizator;
• 2 – identificatorul st ării ST_CUMP_VIEW din care se realizeaz ă
tranzi ția (unic determinat în baza de date);
• 31 – identificatorul evenimentului EV_CUMP_PRINT_PREVIEW ;
evenimentul semnific ă că o entitate a fost aleas ă de c ătre utilizator
pentru Print Preview;
• BMS71 – codul produsului memorat în baza de date pentru c are se
dore ște Print Preview. Nivelul prezentare (PL)
Client 1: navigator XML
XML + XSL = (D)HTML Client 2: navigator DHTML Cerere
HTTP
Metoda
POST
Nivelul WFL
Componenta wfl XML,
XSL
DHTML
96 Comunicarea dintre nivelul de control a fluen ței aplica ției și nivelul de
prezentare
Răspunsul de la nivelul de control al fluen ței aplica ției la client poate fi trimis în
dou ă formate. Dac ă clientul suport ă XML atunci r ăspunsul este trimis ca și un
document XML a șa cum este el primit de la nivelul de logica al apl icatiei. Dacă
clientul nu suport ă XML documentul este convertit în DHTML pe partea d e server
utilizând documentul XML și documentul XSL corespunz ător.
Comunicarea dintre nivelul de control a fluen ței aplica ției și nivelul de logic ă al
aplica ției
Comunica ția între nivelul de control a fluentei aplicatiei și nivelul de logic ă al
aplicatiei este de asemenea bidirec țional ă. Parametrii cererii client sunt convertiti ți
într-o structur ă de mesaj și trimi și către nivelul de logic ă. Se trimit urm ătorii
parametri:
• Tipul clientului care a f ăcut cererea – client XML sau client non-XML;
• rolul utilizatorului;
• identificatorul utilizatorului;
• starea curent ă;
• evenimentul;
• un vector cu trei parametri de intrare;
• doi parametri de ie șire, unul pentru datele XML returnate de BLL și
altul pentru calea la fi șierul XSL utilizat de XML în conversia c ătre
HTML.
Comunicarea dintre nivelul de logic ă și nivelul de fluen ță al aplica ției
Răspunsul de la nivelul de logic ă este primit de c ătre nivelul de fluen ță într-un
document XML, documentul fiind încapsulat într-un șir care con ține și calea c ătre
fi șierul XSL corespunz ător. Fi șierul XSL va fi utilizat în convertirea datelor XML în
HTML atât pe partea de client cât și cea de server.
Figura 35. Comunicarea WFL – BLL Date XML și
fi șier XSL Parametrii
paginii Web Nivel WFL
Nivel BLL Componenta WFL
97 4.6.6 Structura datelor
Structura utilizat ă de c ătre aplica ție este divizat ă în dou ă sec țiuni. Prima
sec țiune este comun ă fiec ărei pagini utilizator iar cea de-a doua sec țiune este specific ă
fiec ărei pagini. Structura datelor este urm ătoarea:
<data>
Structura comun ă…
Structura specific ă…
</data>
Structura comun ă
Structura comuna descrie în format XML mesajul util izat în comunicarea client-
server. Structura este urm ătoarea:
<form>
<EK_CS>va78dc97b-3576-11d4-8f71-00a0d21a4e6e0001 </EK_CS>
<State></State>
<Event></Event>
<Parameter>
<Name>Param1</Name>
<Value>END</Value>
</Parameter>
…
</form>
Aceste date sunt trimise serverului de catre client . Valoarea campului EK_CS
rămâne neschimbat ă la ac țiunea utilizatorului pe pagina HTML si este o valoa re
primita de catre client de la server. Campul <State> este tot o valoare care este
primita de la server si trimisa inapoi fara a fi mo dificata reprezentand starea curenta.
Serverul va interpreta valorile <State> si <Event>, si daca combinatia primita este
una valida, se va trece la starea urmatoare dupa re alizarea actiunii specifice.
Structura specific ă
Fiecare pagină con ține informa ție specifică care este reprezentat ă și structurată
în format XML. De exemplu, informa ția despre o entitate a catalogului este
structurată dup ă cum urmează:
<entity>
<F_P_MAKE>tip1</F_P_MAKE>
<F_P_SERIE>serie1</F_P_SERIE>
98 <F_P_COD>A41</F_P_COD>
<F_P_MODEL>A4 1.8 T/2000</F_P_MODEL>
<F_P_PICTURE>/images/cars/Audi/A4/A41.jpg</F_P_PI CTURE>
<F_P_RP>24760.00</F_P_RP>
<F_P_LINK>http://www.tip1.com</F_P_LINK>
<F_P_LOGO>/IMAGES/CARS/Audi/LOGO.JPG</F_P_LOGO>
</entity>
In exemplul prezentat structura de date specifica c ontine urm ătoarele informatii
relativ la modelul unei masini:
• F_P_MAKE – constructorul modelului;
• F_P_SERIE – seria modelului;
• F_P_COD – codul modelului;
• F_P_MODEL – tipul modelului;
• F_P_PICTURE – calea la imaginea modelului;
• F_P_RP – pre țul;
• F_P_LINK – adresa Web a constructorului.
99 4.6.7 Nivelul de logic ă și nivelul de date
Figura 36. Structura aplica ției. Nivelele de logic ă și de acces la date
Componentele celor dou ă nivele de prezentat sunt urm ătoarele:
• BLL – nivelul de logic ă a aplica ției;
• DAL – nivelul de acces la date ;
• DL – nivelul de date (server de baze de date).
BLL și DAL sunt formate din componente dezvoltate ca și servere in-process
care pot rula individual pe diferite ma șini.
In cadrul aplica ției, un utilizator poate fi în una dintre urm ătoarele trei ma șini de
stare: vizitator, cump ărător sau vănz ător. Componenta Distribuitor este cea
responsabila cu selectarea masinii de stare corespu nzatoare fiecarui utilizator în
func ție de rolul acestuia. Tranzi țiile în cadrul fiecarei ma șini de stare sunt gestionate
de una dintre cele trei componente corespondente al e BLL.
DAL con ține componente cu facilitate de acces la DL pentru diferite tipuri de
ac țiuni.
Nivelul de logic ă a aplica ției (BLL)
Memorarea st ărilor utilizator și trasarea contextului
Creden țialele specifice fiec ărui apel (identificator rol, identificator utilizat or,
starea, trasarea contextului) sunt p ăstrate în DL. In anumite cazuri este posibil ă
accesarea de c ătre BLL a bazei de date evitându-se DAL. Aceasta es te necesar la
fiecare mesaj primit de la PL pentru identificarea utilizatorului. O solu ție alternativă
ar fi p ăstrarea informa țiilor utilizator într-o memorie cash și accesarea acesteia ori de
câte ori este necesar ă identific ării unui utilizator sau al contextului acestuia. ……
…… Internet
DAL Nivelul Prezentare
Nivelul de fluen ță a controlului
PL
WFL
BLL
DL Vizitator Cump ărător Distribuitor
Sursa de date Date formatate XML
Modul
Autentificare Modul Comparare
Modul Acces
catalog Modul Achizitie Vănz ător
100 Pentru un eveniment de intrare se creaz ă un obiect distribuitor care verific ă dac ă
creden țialul primit de la utilizator este unul valid prin c ăutarea acestuia în DL.
Aplica ția are la bază ma șini de stare. O stare denot ă un context utilizator adic ă
un set de date caracteristice unui anumit moment. T recerea dintr-o stare în alta sau
dintr-o ma șină de stare în alta se efectueaz ă pe baza unui eveniment generat în PL.
Acest eveniment determin ă schimbarea contextului de date la trecerea într-o nou ă
stare. Trecerea de la o ma șină de stare la alta se realizeaz ă be baza autentific ării.
Un utilizator este, la un moment dat, într-o stare clar determinat ă și poate
efectua un num ăr determinat de tranzi ții.
Exemplificare:
Fie dou ă roluri alese precum cel de vizitator și cel de cump ărător. Rolul de
vizitator este rolul ini țial a unui utilizator înainte de a se autentifica î n cadrul
sistemului. Dac ă se încearcă for țarea unei st ări autorizate se va intra în mod automat
în starea de login. Dac ă procesul de autentificare se termin ă cu succes, utilizatorul va
trece într-o altă ma șină de stare și î și va modifica rolul din vizitator în cump ărător (de
exemplu). Se disting astfel trei ma șini de stare pentru rolurile detaliate mai sus și
anume: ma șina de stare vizitator (M_V), ma șina de stare login (M_L) și ma șina de
stare cump ărător (M_C). In func ție de starea curent ă, evenimentul ap ărut și alți
parametri de intrare, are loc tranzi ția dintr-o stare în alta, dintr-o ma șin ă de stare în
alta.
Ma șinile de stare sunt memorate în DL dar, în momentul instal ării, acestea sunt
încărcate în BLL. Aceasta nu afecteaz ă scalabilitatea sistemului: fiecare pachet nou
BLL va încărca cele trei ma șini de stare în memorie.
Dacă o persoană încearcă să realizeze opera ții ilegale dintr-un navigator apelând
WFL dintr-o pagin ă, cu parametrii de apel altera ți, se realizeaz ă verificarea
creden țialului în BLL:
• rolul trebuie s ă fie unu valid;
• identificatorul utilizatorului trebuie s ă fie unul valid;
• starea trebuie s ă fie valid ă;
• evenimentul ap ărut trebuie s ă declan șeze o ac țiune valid ă și o tranzi ție
într-o stare valid ă.
Este implementat ă și ac ționarea butonului Back și modificarea st ării curente
(trasarea contextului) a unui utilizator în acest c az. Astfel, serverul memoreaz ă
valoarea actual ă a st ării clientului (SAS) și, la sosirea cererii, creden țialul con ține altă
valoare (starea actualizat ă a clientului – UAS). O alt ă problem ă este cazul în care la
solicitarea Back utilizatorul va trimite cereri dintr-o pagin ă apar ținând unei alte
ma șini de stare. In acest moment Dispatcher-ul trebuie s ă recunoască faptul c ă s-a
ac ționat un buton Back și nu este un hacker care încearc ă să trimită parametri diver și
pentru a intra în sistem. Problema este tratat ă în func ție de utilizator și tipul ma șinii de
stare.
Tabelul de mai jos ilustreaz ă faptul c ă, în cazul în care SAS are tipul vizitator
sau login, ac ționarea butonului Back nu are implica ții deoarece datele care se doresc a
fi accesate sunt date publice, care nu necesit ă autentificare.
Când SAS are tipul cump ărător și UAS are tipul login sau vizitator,
utilizatorului i se cere s ă execute logoff dac ă dore ște să acceseze pagini neautorizate.
In cazul invers, când UAS are tipul cump ărător și SAS are tipul login sau vizitator,
utilizatorului i se cere s ă efectueze login dac ă dore ște să acceseze pagini (implicit
date) autorizate.
101
Tabelul 4. Gestionarea st ărilor la ac ționarea butonului Back
UAS SAS VIZITATOR LOGIN CUMP ĂRĂTOR
VIZITATOR – – Please logoff!
LOGIN – – –
CUMP ĂRĂTOR Please login! Please login! Verific ări suplimentare
Dup ă cum este ilustrat în tabelul 4, în cazul în care U AS este egal cu SAS și
egale cu cump ărător, sunt necesare verific ări suplimentare. In baza de date este
păstrată o listă con ținând toate st ările vizitate de c ătre un cump ărător. Dacă cererea
sose ște dintr-o stare memorat ă înseamnă că utilizatorul a ajuns în acel punct prin
ac ționarea butonului Back și aceasta este o ac țiune autorizat ă.
Not ă: Este important c ă toate verific ările sunt realizate dup ă decriptarea
creden țialului care include un UUID (identificator utiliza tor) care are șanse
mari s ă fie unic mondial. A șadar, dac ă un hacker încearc ă să trimită cereri
către aplica ție pentru a accesa st ări autorizate, acesta necesit ă atât o cheie
valid ă criptată cât și parametri de intrare corec ți.
Componenta de distribu ție
Pentru fiecare intrare utilizator este apelat un mo dul de distribu ție (Distribuitor).
Acesta realizeaz ă urm ătoarele ac țiuni:
• verificarea creden țialului. Dacă nu este valid se genereaz ă mesaj de
eroare;
• identificarea rolului utilizator din creden țial;
• crearea unui obiect utilizator corespunz ător creden țialului;
• trimiterea evenimentului c ătre obiectul utilizator și așteptarea
răspunsului (în mod normal un fi șier XML);
• trimiterea r ăspunsului c ătre client;
• gestionarea erorilor.
Componente utilizator
BLL este accesat de c ătre componente WFL la sosirea unei cereri. In func ție de
parametrii de intrare și de creden țial, Distribuitorul creaz ă o componentă specifică
rolului utilizator, și evenimentele de intrare sunt trimise acestei comp onente create.
Distribuitorul utilizeaz ă polimorfismul la nivelul interfe țelor: apelează metoda
Event asupra unui obiect utilizator creat f ără să știe tipul obiectului. Obiectul utilizator
prime ște starea curent ă, evenimentul și parametrii de intrare, ob ține starea urm ătoare
și ac țiunea de realizat din ma șina de stare. De asemenea, ma șina de stare furnizeaz ă
id-ul interfe ței și al clasei pentru obiectul DAL de instan țiat (dacă este necesar).
In implementare, se creeaza un obiect DAL care prim este parametrii de intrare
curen ți. Asupra acestui obiect se va apela metoda specifi ca ac țiunii de efectuat,
ob ținându-se în acest mod datele rezultat. Obiectul cr eat va accesa baza de date, va
apela procedura/procedurile stocate și va transforma rezultatul într-unul în format
XML.
102 In cazul în care se execut ă logoff aceste ac țiuni vor fi rezolvate în cadrul
componentelor utilizator f ără accesarea bazei de date.
Componente de verificare a constrângerilor
In cazul în care un utilizator are un timp de inact ivitate acesta va fi de-logat
automat. Pentru aceasta exist ă un utilitar administrativ care are un timer ce va apela
automat componenta de verificare. Aceasta component ă verifică expirarea timpului
limită de la ultima ac țiune a unui utilizator. Dac ă rezultatul este true (timpul a
expirat), informa ția utilizator este men ținută în urm ătoarea manier ă: dac ă ma șina de
stare este cea de vizitator, informa ția aferentă acestuia va fi ștears ă din baza de date;
dac ă utilizatorul este un cump ărător informa ția va fi men ținută în baza de date pentru
o perioad ă de 24 de ore. Dac ă utilizatorul nu revine în acest interval și nu a emis o
comand ă informa ția acestuia va fi ștears ă; dac ă cump ărătorul e emis o comand ă
aceasta va fi re ținută în baza de date un timp indefinit.
Există trei tipuri de componente verificatoare pentru fie care rol. Practic, fiecare
tip de obiect verificator și rol utilizator pot fi instalate pe calculatoare d iferite,
realizându-se în acest mod scalabilitatea impus ă. Modelul interfe țelor pentru obiectele
verificatoare este prezentat în figura 37.
Gestionarea erorilor
Pentru gestionarea erorilor fiecare component ă încearcă să-și rezolve excep țiile
și să-și forwardeze r ăspunsul de eroare nivelului superior. In acest mod se reg ăse ște
descrierea exact ă a erorii pentru utilizator și aceast ă eroare va fi scris ă și în fi șierul de
log.
Dacă intervine o eroare în nivelul DAL se returneaz ă un cod de eroare, iar în
func ție de acest cod se lanseaz ă o ac țiune de gestionare a erorii, ac țiune ob ținută în
func ție de ma șina de stare și de componenta DAL. Acest mecanism poate fi reiter at
pân ă la producerea unui rezultat valid de gestionare a erorii.
In cadrul BLL a fost introdus ă de asemenea o component ă de gestionare a
erorilor. Aceasta este apelat ă de catre Distribuitor în cazul în care se declan șează o
eroare. In func ție de valoarea codului de eroare se va afi șa utilizatorului un mesaj de
eroare. Figura 37. Modelul interfe țelor pentru obiectul de verificare
103 4.6.8 Nivelul de acces la date (DAL)
Evenimentele declan șatoare de st ări con ținute în cele trei ma șini de stare au fost
grupate în func ție de starea din care pot fi declan șate. De exemplu exist ă grupuri de
evenimente pentru Actualizare_Ordin, Contul_Meu, Co mparare, etc. Gestionarea unui
grup de evenimente este realizat ă de componente separate DAL de exemplu pentru
lista de mai sus: DAMUO (Data Access Module Update Order), DAMMA (Data
Access Module My Accounts), DAMCF (Data Access Modu le Comparison Folder).
Aceste componente DAL au ca și date de intrare codul ac țiunii de realizat și un
anumit num ăr de parametri. In func ție de codul ac țiunii se apeleaz ă o procedur ă iar
datele rezultat sunt formatate într-un fi șier XML.
In cazul unei excep ții se returnează codul erorii c ătre componenta utilizator.
Dup ă cum se poate observa și în figura 38, interfe țele DAL implementeaz ă o
interfa ță de baz ă, pentru crearea unei componente utilizându-se poli morfismul la nivel
de interfa ță prin apelarea func ției Action . Identificatorul clasei și al interfe ței
obiectului DAL se ob țin din ma șina de stare utilizându-se starea curent ă și
evenimentul declan șator.
Figura 38. Modelul interfetelor DAL
104
105 5 Rezultate experimentale
In cadrul acestui capitol se detaliaz ă testele realizate și rezultatele
experimentale. S-au realizat urm ătoarele tipuri de teste: teste func ționale și teste de
determinare a nivelului de siguran ță a datelor.
Testele func ționale realizate sunt:
– teste de performan ță ;
– teste de scalabilitate.
Testele func ționale determin ă pe de o parte nivelul de performan ță al aplica ției
distribuite prin evaluarea timpilor de execu ție și, pe de alt ă parte, modificarea acestor
timpi la scalarea aplica ției (teste de scalabilitate). Ceea ce s-a urm ărit au fost aspectele
legate de performan ța unei aplica ții de comer ț electronic care implementeaz ă modelul
SCAR-ACE deoarece, prin introducerea unei ma șini de stare, pot aparea eventuale
intârzieri. Testele au demonstrat timpi de r ăspuns mici la o înc ărcare a aplica ției cu
300 de utilizatori simultani și au validat modelul SCAR-ACE din punct de vedere
func țional.
Testele de determinare a nivelului de siguran ță a datelor sunt:
– teste de răspuns la un atac simulat;
– teste de conformitate cu cerin țele modelului SCAR-ACE.
Testele de r ăspuns la un atac simulat î și propun determinarea reac ției aplica ției
la încercarea de fraudare a sistemului prin ob ținerea și modificarea creden țialelor.
Testele au demonstrat siguran ța aplica ției în fa ța unui atac.
Testele de conformitate cu cerin țele modelului SCAR-ACE sunt teste care
determin ă modul de realizare a constrângerilor impuse (modul de realizare a separ ării
îndatoririlor statice și dinamice, modul de realizare a mo ștenirii rolurilor și modul de
desemnare și acordare a privilegiilor). Testele au demonstrat conformitatea aplica ției
cu modelul SCAR-ACE și au validat modelul.
5.1 Teste de performan ță
Ipoteza de verificat: timpul de r ăspuns la introducerea ma șinilor de stare cre ște
la înc ărcarea / desc ărcarea unei ma șini de stare în / din memorie.
Aplica ția de comer ț electronic a fost testat ă pentru dou ă tipuri de achizi ții:
pentru ma șini și pentru calculatoare. Func ționalit ățile dezvoltate au fost cele pentru
rolurile de vizitator, cump ărător, vânz ător și administrator, și au fost implementate
ac țiunile necesare realizarii unei comenzi.
Testele efectuate au fost cele de verificare a timp ului de r ăspuns în condi țiile în
care au fost lansate 300 de taskuri în paralel.
106 5.1.1 Descrierea testelor
Sistemul a fost testat în urm ătoarea configura ție: serverul – o ma șin ă HP cu
procesor Pentium(R) 4 CPU 2.53GHz, 1GB RAM și 2 clienti cu aceea și configura ție.
Pentru scalabilitate s-au utilizat dou ă servere si doi clien ți, toate cu configura ția de
procesor Pentium(R) 4 CPU 2.53GHz și 1GB RAM.
Testele au constat din lansarea în execu ție a 300 de taskuri care s ă ruleze în
paralel. Astfel:
– primele 100 de taskuri realizeaz ă ini țierea de sesiuni de c ătre utilizatori
(în rolul de vizitator). Pentru fiecare dintre aces te taskuri serverul a
executat urm ătoarele ac țiuni:
o crearea unui identificator utilizator și păstrarea acestuia în
memorie;
o înc ărcarea ma șinii de stare vizitator în memorie din baza de
date;
o memorarea st ării curente (ST_HOME) în memorie ca și
stare actual ă a utilizatorului nou creat;
o trimiterea paginii “Home” pe ma șina client împreun ă cu
datele de identificare a utilizatorului și a st ării curente.
– urm ătoarele 100 de taskuri sunt pentru trecerea utiliza torilor din rolul de
vizitator în rolul de cump ărător prin autentificare. Pentru fiecare task
serverul execut ă urm ătoarele ac țiuni:
o verificarea datelor de autentificare;
o descarc ărea ma șinii de stare vizitator din memorie și
înc ărcarea ma șinii de stare cump ărător în cazul în care
datele de autentificare au fost corecte (actiunea efectiva de
login);
o emiterea unui mesaj de eroare dac ă datele de autentificare
au fost gre șite;
o trimiterea unei pagini de r ăspuns pe ma șina client (fie
pagina cu informa ții personale a cump ărătorului fie o
pagin ă de eroare) împreun ă cu datele de identificare a
utilizatorului și a st ării curente.
– ultimele 100 de taskuri reprezint ă încheierea sesiunilor de lucru. Serverul
execut ă urm ătoarele ac țiuni în acest caz:
o desc ărcarea ma șinii de stare curente din memorie (ac țiunea
de logoff);
o desc ărcarea datelor de context din memorie pentru fieca re
utilizator (starea, informa ții de acces);
o scrierea datelor ce necesit ă a fi păstrate persistent în baza de
date (dac ă a modificat datele de identificare sau non-
identificative, co șul de cump ărături sau cererile ferme).
Testele care s-au f ăcut au urm ărit urm ătorii trei timpi:
– timpul de execu ție pentru login (figura 39) si timpul de execu ție
pentru logoff (figura 40);
– timpul mediu al execu ției;
– timpul total al execu ției.
A fost considerat timpul de execu ție pentru login ca și test separat deoarece în
acest moment este înc ărcat ă ma șina de stare în memorie (este ac țiunea cea mai mare
107 consumatoare de resurse). Timpul de execu ție la logoff reprezint ă evolu ția sistemului
la desc ărcarea ma șinii de stare din memorie si salvarea datelor in ba za de date.
Rezultatele ob ținute sunt cele din figurile de mai jos (figurile 3 9, 40).
Ini țierea sesiunii utilizator
0.000000 0.000100 0.000200 0.000300 0.000400 0.000500 0.000600 0.000700 0.000800
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97
Nr. de utilizatori Timp (s) Timpul la
ac țiunea
de login
Timpul
mediu de
execu ție
Timpul
total de
execu ție
Figura 39. Timpii la autentificarea utilizatorilor
Terminarea sesiunii utilizator
0.000000 0.000100 0.000200 0.000300 0.000400 0.000500 0.000600 0.000700 0.000800 0.000900
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93
Nr. utilizatori Timp (s) Timpul la
ac țiunea
de logoff
Timpul
mediu de
execu ție
Timpul
total de
execu ție
Figura 40. Timpii la terminarea sesiunii utilizator
5.1.2 Interpretarea rezultatelor
Toate cele 300 de taskuri sunt lansate în paralel i ar succesiunea ac țiunilor
executate de server este descris ă în sec țiunea anterioar ă. Trebuie avut în vedere c ă
de și taskurile au fost lansate în paralel a existat to tu și o secven țialitate a acestora
deoarece întreaga aplica ție a fost înc ărcat ă pe un server cu un singur procesor.
108 Rezultatele ar fi sim țitor mai bune dac ă modulele program ar fi înc ărcate pe mai multe
ma șini. A șadar rezultatele ob ținute sunt cele pentru cel mai defavorabil caz.
Analizând graficele din figurile 39 si 40 se observ ă c ă la autentificare si
respectiv la terminarea sesiunii utilizator, cei tr ei timpi studia ți nu au aceea și valoare.
In graficul din figura 39 timpul mediu de execu ție este de circa dou ă ori mai mic
fa ță de timpul ac țiunii de login, si cu circa 50% mai mare fa ță de timpul total de
execu ție.
Tot din grafic se observ ă c ă la al 20-lea utilizator exist ă un vârf al timpului de
execu ție. Aceasta deoarece în acel moment server-ul încar c ă ma șina de stare a
cump ărătorului (conform fisierelor de test) pentru primul task care are nevoie de
aceasta (în mod firesc, în acest moment primul util izator care a fost lansat in sistem
are nevoie de ma șina de stare cump ărător pentru a-și realiza taskurile impuse).
Inc ărcarea unei ma șini de stare are loc doar pentru primul utilizator dintr-un
anumit rol și desc ărcarea acesteia are loc la ultimul utilizator care a fost în acel rol.
Așadar timpul de execu ție al celui de-al 20-lea utilizator încapsuleaz ă și
înc ărcarea ma șinii de stare cump ărător pentru primul utilizator. Faptul c ă se realizeaz ă
înc ărcarea ma șinii de stare (pentru primul utilizator din sistem) simultan cu lansarea
celui de-al 20-lea utilizator, este dependent ă de configura ție și de puterea de calcul a
procesorului (eventual procesoarelor) în lucru. Pen tru o configura ție diferit ă aceasta ar
putea interveni într-un alt moment și pentru un alt utilizator.
Analizând în continuare figura 39 (dup ă cel de-al 20-lea utilizator) se observ ă c ă
timpii devin mai mici și relativ constan ți. Exist ă totu și și în continuare anumite vârfuri
și aceasta datorit ă înc ărc ării serverului, în momentele în care are mai multe ac țiuni
paralele de executat.
Timpul mediu prezint ă vârfuri mai atenuate fa ță de cele ale timpului ac țiunii de
login si mai accentuate fa ță de timpul total de execu ție. Se observ ă c ă timpul total de
execu ție este relativ constant în jurul valorii de 0.0001 s.
Timpii din figura 40 urm ăresc evolu ția celor din figura 39 și aceasta deoarece la
logoff ma șina de stare este desc ărcat ă din memorie deci și in accest caz exist ă timpi
de întârziere prin consumarea mai multor resurse.
Concluzie : introducerea ma șinilor de stare implic ă cre șterea timpului de
execu ție la înc ărcarea /desc ărcarea acestora în / din memorie. To ți timpii de execu ție
subsecven ți nu cresc. Timpul total de execu ție nu este puternic influen țat de lucrul cu
ma șini de stare.
5.2 Teste de scalabilitate
Ipoteza 1 de verificat: implementarea scalat ă a modelului SCAR-ACE are timpi de
răspuns mai mici decât implementarea nescalat ă a arhitecturii cu formuri de comenzi.
Sistemul a fost scalat pe dou ă servere și a fost testat func țional la use case-ul din
figura 41 (test 1) si la use case-ul de autentifica re din figura 8 (test 2).
Aplica țiile care au fost selectate pentru testarea timpilo r obtinu ți prin scalare
sunt:
– Prima aplica ție implementeaz ă modelul SCAR-ACE scalat;
– A doua aplica ție implementeaz ă arhitectura cu formuri de comenzi
nescalata.
109
Au fost selectate aceste dou ă aplica ții pentru a se realiza și o comparare între
cele dou ă implement ări de sisteme de comer ț electronic.
Primul test (use case-ul din figura 41) implementea z ă urm ătoarea
func ționalitate: selectarea celei mai ieftine oferte car e respect ă anumite criterii
func ționale. Oferta este preluat ă atât din produsele la mâna a doua cât și din cele noi
oferite de sistem, utilizatorului oferindu-i-se mai apoi op țiunea de a o selecta pe cea
care îndepline ște criteriile propri. A fost selectat acest use cas e deoarece prezint ă o
ac țiune complex ă și se pot testa comparativ timpii de acces pentru sc alare.
Al doilea test de scalabilitate verifica timpii de raspuns pentru actiunea de login
(use case-ul din figura 8).
Figura 41. Use case pentru testarea scalabilit ății
Ipoteza 2 de verificat: timpii de r ăspuns ai implementarii modelului SCAR-ACE scad
prin scalare.
S-a realizat testarea timpilor de r ăspuns ai implement ării modelului SCAR-
ACE atât scalat pe dou ă servere cât si nescalat (rulând pe un singur serve r) pentru
ac țiunea de login. Au fost comparate cele dou ă variante ale implement ării modelului
SCAR-ACE (cea scalat ă si cea nescalat ă) în func ție de num ărul de utilizatori care au
participat in sistem.
5.2.1 Interpretarea rezultatelor
Pentru ipoteza 1:
Timpii de r ăspuns ai primului test de scalabilitate sunt ilustr a ți in figura 42. S-au
luat în considerare 100 de fire de execu ție paralele. Se poate observa o diferen ță între
timpii de r ăspuns pentru cele dou ă situa ții: prima aplica ție (modelul SCAR-ACE
scalat) și cea de a doua aplica ție (arhitectura cu formuri de comenzi nescalata), și
anume un timp de execu ție mai mic pentru cazul aplica ției care implementeaz ă
modelul SCAR-ACE.
Testul al doilea de scalabilitate a fost selectat p entru o ac țiune simpl ă
(înregistrare/login utilizator). Pentru a fi conclu dent s-a luat in considerare un num ăr
de 170 de utilizatori simultani. Rezultatele testul ui 2 sunt ilustrate în figura 43. Se
observ ă si in acest caz timpi de r ăspuns mai mici în cazul aplica ției care
implementeaz ă modelul SCAR-ACE.
Baza
de
date
Interfa ța
Utilizator
Grafic ă Distribuitor
Manager
Utilizatori Componenta
Utilizator Modul
Acces
Date
Componenta
logic ă ST-ANY
Home
Ma șina de
stare
110 Scalabilitate
0,00000 0,00005 0,00010 0,00015 0,00020 0,00025
1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97
Nr. fire de execu ție T im p (s) Aplica ția
formuri
comenzi
Aplica ția
SCAR-
ACE
Figura 42. Rezultatele testului 1 de scalabilitate
Scalabilitate
0,00000 0,00005 0,00010 0,00015 0,00020 0,00025 0,00030 0,00035 0,00040 0,00045 0,00050
1 11 21 31 41 51 61 71 81 91 101 111 121 131 141 151 161
Nr. fire de execu ție T im p (s ) Aplica ția
formuri
comenzi
Aplica ția
SCAR-
ACE
Figura 43. Rezultatele testului 2 de scalabilitate
Concluzia 1: Timpii de r ăspuns ai aplica ției care implementeaza modelul
SCAR-ACE scalat sunt mai mici decât cei ai aplica ției care implementeaza arhitectura
cu formuri de comenzi nescalate.
111 Pentru ipoteza 2:
Evolu ția timpilor de r ăspuns între cele dou ă variante în func ție de num ărul de
utilizatori simultani este ilustrat ă în figura 44. Se observ ă o diferen ță din ce în ce mai
mare a timpilor de execu ție odat ă cu cre șterea num ărului de utilizatori.
Figura 44. Variatia timpilor totali de executile in aplicatia scalata
Concluzia 2: Timpii de r ăspuns ai aplica ției scalate sunt mai mici decât cei ai
aplica ției nescalate.
5.3 Teste de r ăspuns la atac simulat
Ipoteza de verificat: creden țialul nu poate fi ob ținut din nici o stare a aplica ției.
Atacul asupra aplica ției se refer ă la încerc ări de a penetra sistemul în mod
fraudulos. In cazul modelului SCAR-ACE acestea ar î nsemna încerc ări de acces la
informa ții confiden țiale, informa ții accesibile în mod normal doar prin autentificare .
Astfel de informa ții confiden țiale ar putea fi:
– informa ții de identitate a utilizatorului;
– informa ții relativ la comenzile realizate;
– informa ții de plat ă;
– informa ții despre starea livr ării unui bun.
Pentru a se realiza un atac ar fi posibile urm ătoarele dou ă variante:
a) accesul la creden țial;
b) reconstituirea unui creden țial.
Accesul la creden țial:
Modul în care modelul SCAR-ACE este realizat nu per mite vizualizarea
creden țialului acesta fiind ascuns utilizatorului nefiind prezent în linia de comand ă. 0 0.002 0.004 0.006 0.008
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49
Nr. utilizatori Timp
Aplica ția
nescalat ă
Aplica ția
scalat ă
112 Orice încercare de vizualizare este penalizat ă prin emiterea unei excep ții și afi șarea
unei pagini de eroare. Presupunând c ă în mod fraudulos s-ar fura un creden țial în
timpul accesului unui utilizator la informa țiile proprii autorizate, sistemul verific ă în
mod permanent informa țiile relativ la adresa de IP de la care s-a demarat accesul și
încercarea de acces de la o alt ă adres ă determin ă încetarea automat ă a aplica ției și
realizarea unui log off for țat.
S-au realizat diverse teste de simulare ale unui at ac prin încercarea de
vizualizare a unui creden țial în diverse st ări ale aplica ției și toate acestea s-au soldat
cu închiderea automat ă a aplica ției.
Concluzia 1: Credențialele nu se pot ob ține din aplica ție.
Reconstituirea unui creden țial:
Dac ă un atacator reu șește totu și s ă ob țin ă în mod fraudulos un creden țial acesta
nu ar putea fi utilizat pe durata unei sesiuni util izator (vezi punctul a). Ar mai avea
posibilitatea de a-l utiliza dup ă închiderea sesiunii utilizator. In acest ultim caz exist ă
îns ă urm ătoarea interdic ție: creden țialul nu mai e valabil dup ă închiderea unei sesiuni
utilizator și aceasta deoarece identificatorul unui utilizator expir ă dup ă închiderea
sesiunii și la orice acces ini țiat acest identificator utilizator se schimb ă. Mai mult
decât atât identificatorul utilizatorului este acor dat de c ătre server și nu clientul este
cel ce asigneaz ă acest num ăr.
S-a încercat reconstruirea de creden țiale și s-au simulat atacuri îns ă nu s-a reu șit
penetrarea sistemului nici pentru st ări autorizate și nici pentru cele neautorizate.
Concluzia 2 : Creden țialele, chiar dac ă ar putea fi ob ținute prin diverse mijloace,
nu pot fi utilizate în cadrul aplica ției deoarece au un timp limitat și foarte scurt de
valabilitate.
5.4 Teste de conformitate cu cerin țele modelului SCAR-ACE
Modelul SCAR-ACE impune anumite cerin țe și anume:
a) sistemul trebuie s ă realizeze separarea îndatoririlor;
b) sistemul trebuie s ă implementeze mo ștenirea rolurilor.
Separarea îndatoririlor și mo ștenirea rolurilor se implementeaz ă prin alocarea de
ma șini de stare diferite pentru fiecare rol. Trecerea de la o ma șin ă de stare la alta se
realizeaz ă la login. Mo ștenirea implic ă posibilitatea de a accesa, dintr-o ma șin ă de
stare situat ă la nivel ierarhic superior, st ări dintr-o ma șin ă de stare situat ă la un nivel
ierarhic inferior (de exemplu ma șina de stare vizitator poate fi accesat ă din ma șina de
stare cump ărător).
Ipoteza de verificat: aplica ția realizeaz ă separarea îndatoririlor.
Testarea s-a realizat cu utilitarul Silktest și a demonstrat conformitatea
func țion ării cu cerin țele modelului SCAR-ACE prin ob ținerea de rezultate corecte. S-
au efectuat ac țiuni în care au fost activi 100 de utilizatori și au fost lansate simultan
406 fire de execu ție. Pentru verificarea separ ării îndatoririlor s-a încercat for țarea
113 atribu țiilor rolului de vizitator prin încercarea de acces are a unor informa ții private
specifice rolului de cump ărător:
– informa ții de identitate a unui cumparator – încercare sold at ă cu e șec;
– informa ții relativ la comenzile realizate de un cumparator – încercare
soldat ă cu e șec;
– informa ții de plat ă a unei comenzi – încercare soldat ă cu e șec;
– informa ții despre starea livr ării unui bun – încercare soldat ă cu e șec.
Concluzie: Aplica ția este conform ă cu modelul SCAR-ACE și implementeaz ă
separarea îndatoririlor.
Ipoteza de verificat: aplica ția realizeaz ă mo ștenirea rolurilor.
Pentru verificarea mo ștenirii rolurilor s-a testat o secven ță de ac țiuni care
implică accesul dintr-o ma șin ă de stare în alta. Pentru testarea acestei func ționalit ăți s-
au realizat test case-uri care s ă simuleze secven țe de ac țiuni atât autorizate cât și
neautorizate, teste de la o stare neautorizat ă la una autorizat ă și teste de la o stare
autorizat ă înapoi la una neautorizat ă.
Exemplu de secven ță testat ă:
1. se ini țiaz ă o sesiune;
2. se acceseaz ă catalogul de produse;
3. se realizeaz ă autentificarea;
4. se selecteaz ă un produs în co șul de cump ărături;
5. se efectueaz ă plata;
6. se verific ă comanda;
7. se revine la pagina Home.
Aceast ă secven ță a fost realizat ă pas cu pas și implic ă acesarea urm ătoarelor
ma șini de stare:
1. ini țiere sesiune – ma șina de stare vizitator;
2. accesare catalog de produse – ma șina de stare vizitator;
3. autentificare – ma șina de stare login și trecere în ma șina de stare
cump ărător;
4. vizualizare catalog de produse – ma șina de stare vizitator (prin mo ștenire);
5. comparare produse – ma șina de stare vizitator (prin mo ștenire);
6. selectare produs – ma șina de stare vizitator (prin mo ștenire);
7. inserare produs în co șul de cump ărături – ma șina de stare cump ărător;
8. efectuare plat ă – ma șina de stare cump ărător;
9. verificare comand ă – ma șina de stare cump ărător;
10. revenire la pagina Home – ma șina de stare vizitator (prin mo ștenire);
11. logoff.
Concluzie: Aplica ția este conform ă cu modelul SCAR-ACE și implementeaz ă
mo ștenirea rolurilor.
114
115 6 Concluzii și dezvolt ări ulterioare
Odat ă cu cre șterea necesit ății de aplica ții deschise și distribuite cre ște și cererea
pentru politicile de control al accesului. Astfel, din ce în ce mai multe servicii se vor
baza pe o infrastructur ă care s ă le ofere securitatea accesului. Aceste cerin țe necesita
politici adaptive capabile s ă accepte taskuri colaborative care s ă își îndeplineasc ă
sarcinile prin asigurarea autoriz ării accesului.
6.1 Contribu ția proprie
In aceast ă tez ă s-a descris un model care furnizeaz ă o politic ă de control al
accesului bazat pe roluri în sisteme deschise și distribuite, model care constituie în
ansamblul s ău contribu ția proprie major ă. In detaliu s-a contribuit la urm ătoarele:
– o analiza a modelelor RBAC existente, a cercet ărilor actuale și a
colectivelor care au implementat modele RBAC;
– o abordare original ă a componentelor RBAC într-o manier ă în care s ă
fie solu ționate aspectele legate de controlul accesului baza t pe roluri în
sisteme distribuite și deschise. Astfel, s-a extins modelul standard
RBAC cu ma șini de stare, prin intermediul c ărora se realizeaz ă
acordarea drepturilor la nivel de ac țiune. Aceste ma șini de stare au fost
introduse în construc țiile modelului astfel încât s ă poat ă fi exprimate
rela țiile dintre componente. Modelul SCAR-ACE include și o ierarhie
de roluri, ierarhie de tip arbore care permite mo ștenirea drepturilor;
– un model de realizare a rela țiilor de constrângere și de separare static ă
a îndatoririlor tot prin mecanismul bazat pe utiliz area unei ma șini de
stare pentru fiecare rol. Astfel, un utilizator c ăruia i-a fost atribuit un
rol are ata șat ă una și doar una dintre ma șinile de stare;
– modelarea sistemului SCAR-ACE prin detalierea pe ni vele: SCAR-
ACE 0, SCAR-ACE 1, SCAR-ACE 2 și SCAR-ACE 3;
– definirea modelului formal prin analiza constrânger ilor autoriz ării
bazate pe roluri, si a modului de desemnare a privi legiilor în SCAR-
ACE. S-au determinat și s-au descris astfel nivelele de acordare a
privilegiilor cu ajutorul UML;
– identificarea modalitatii de acordare a drepturilor în SCAR-ACE prin
intermediul creden țialelor și descrierea componen ței acestora ;
– definirea politicii de acordare a privilegiilor și a algebrei acestei
politici;
– modelarea accesului prin intermediul ma șinilor de stare și descrierea
modului în care este realizat controlul accesului î n SCAR-ACE prin
caracterizarea rolurilor și identificarea constrângerilor asupra acestora;
– definirea modelului formal al SCAR-ACE și exemplificarea acestuia
pentru un caz concret;
– identificarea fazelor specific ării constrângerilor de autorizare:
o faza de analiză static ă;
o faza de verificare/actualizare;
o faza de planificare;
116 o ma șina de stare;
o interfa ța utilizator grafic ă;
o faza de rulare.
– analiza aplicatiilor de comert electronic, a roluri lor si a arhitecturilor
existente;
– realizarea implementarii modelului SCAR-ACE si a va lidarii acestuia
prin realizarea de studii de caz si obtinerea de re zultate experimentale.
6.2 Dezvolt ări ulterioare
Prezenta tez ă poate fi considerat ă un pas ini țial în cercetarea politicilor
controlului accesului bazat pe roluri în sistemele deschise și distribuite. Exist ă mai
multe posibile dezvolt ări ulterioare detaliate în paragrafele urm ătoare.
Politica abordat ă extinde modelul de baz ă RBAC astfel încât sunt suportate
componentele standard c ărora li se adaug ă componente specifice necesare gestion ării
accesului cu ajutorul ma șinilor de stare. Aceste componente proprii pot fi e xaminate
pentru a se determina dac ă se pot utiliza în tranzitia de la un sistem RBAC e xistent la
altul.
Modelul SCAR-ACE poate deveni destul de complex dac ă se iau în considerare
ierarhii diferite de roluri, modelul actual fiind s pecific ierarhiilor de roluri de tip
arbore. O extensie ar putea lua in considerare si a lte tipuri de ierarhii.
Abordarea curenta organizeaz ă și structureaz ă politicile de control al accesului
în aplica țiile de comer ț electronic dar acest model poate fi investigat și pentru alte
tipuri de aplica ții. Ma șinile de stare care constituie extensiile sunt, în general vorbind,
ni ște grafuri și implementarea acestora necesit ă cuno știn țe avansate. O direc ție nou ă
ar putea implementa o interfa ță grafic ă pentru designul unei aplica ții bazate pe
modelul SCAR-ACE care s ă aib ă drept intrare st ările, evenimentele și tranzi țiile
dintre st ări și s ă genereze ca și ie șire ma șinile de stare.
Aplica ția de comer ț electronic ofer ă suportul in implementarea modelului
SCAR-ACE pentru controlul accesului bazat pe roluri . Aceast ă aplica ție include atât
componente de business cât și componente de administrare, componente care fie
formeaz ă grupuri fie sunt predefinite în sistem. Unele comp onente au nevoie de
condi ții prerechizite. O direc ție de cercetare const ă în extinderea p ărții de business
astfel încât s ă poat ă fi gestionate diverse verticale cu includerea de f acilit ăți (precum
achizi ții de c ărți cu includerea profilului cump ărătorilor pentru notificare și includerea
contextului în care cump ărarea are loc).
Pe de alta parte politica de componente poate fi ma rcat ă cu elemente de context,
permi țând astfel administratorului s ă grupeze componente în func ție de anumite
condi ții. Aceasta ar permite vederi asupra politicilor de componente posibil a fi
exploatate sub forma unor tools-uri de vizualizare. In func ție de punctul de vedere
considerat s-ar putea determina de exemplu cump ărători care satisfac anumite criterii
fie din punct de vedere al securitatii fie din punc t de vedere al bunurilor achizi ționate.
O alt ă extensie posibil ă a modelului implic ă asocierea rolurilor la procese de
business. In acest caz s-ar permite utilizarea mode lului pentru un workflow în care
ma șina de stare urm ăre ște fluen ța p ărții de business a unei aplica ții. Chiar în contextul
actual modelul urm ăre ște fluen ța controlului și, în acest sens, modific ările ar fi minore
și ar consta în ad ăugarea de etichete de proces.
117 SCAR-ACE ia în considerare restric ții la nivel înalt considerând primitivele
modelului ca fiind rolurile, drepturile și ma șina de stare. Pentru a se netezi diferen țele
dintre diferite modele RBAC ar fi de interes o cerc etare în care primitivele ar fi
triplele (obiect, acces, ac țiune) și extinderea prin crearea unor politici echivalente .
Aceast ă cercetare ar consta, în special, în determinarea c onstrângerilor.
O posibilitate de extindere ar fi prin încapsularea componentelor modelului
SCAR-ACE într-o interfa ță între diferite modele RBAC existente. Fiecare mode l ar fi
o stare în cadrul ma șinii de stare și s-ar putea realiza cooperarea între diferite mode le
RBAC. In astfel de medii, politicile interfe ței se pot utiliza în medierea diferen țelor
dintre diferitele domenii de control al accesului. Primul scop al politicilor de interfa ță
ar fi cel de a permite accesul între politicile de domenii. In cazul în care este posibil ă
o cooperare, aceasta ar putea depinde și de politicile de administrare. In anumite
cazuri tranzi țiile între modele s-ar putea realiza pe baz ă de încredere adic ă f ără
necesitatea autentific ării. Astfel apare posibilitatea extinderii pentru p olitici de
conformitate pentru deciziile colabor ării inter-domenii, decizii bazate pe încredere,
dup ă care s-ar putea utiliza politicile de interfa ță pentru a realiza în mod automat
colaborarea între modele.
Politica de gestionare a drepturilor furnizeaz ă un mijloc de control al accesului
la o granularitate foarte fin ă. Aceste drepturi sunt obtinute în SCAR-ACE prin
intermediul ma șinii de stare. Aceste drepturi pot fi îns ă ordonate într-o ierarhie care s ă
permit ă o politic ă mai concis ă de acordare a acestora. O extensie posibil a fi ad us ă
drepturilor ar fi asocierea acestora cu un factor d e risc. Astfel, ac țiunile permise nu
sunt egale din punct de vedere al r ăului poten țial pe care îl pot aduce în sistem la o
folosire defectuoas ă. Prin asocierea acestora cu un factor de risc se p ot emite anumite
politici care s ă specifice superviz ări suplimentare in acordarea accesului pentru
drepturile cu factor ridicat de risc. Astfel, un ri sc ar fi o valoare care, în func ție de
unul sau mai multe praguri, ar avea sau nu nevoie d e superviz ări suplimentare.
Printre motiva țiile importante ale cercet ării prezente este dezvoltarea unei
politici de acces în sistemele distribuite și deschise care s ă controleze accesul în
func ție de rolul utilizatorului. O extensie ar fi extind erea în cadrul diverselor aplica ții
precum cele din domeniile: s ănătate, telecomunica ții, gestionarea resurselor umane și
materiale, și orice alte servicii Web în care se pot eviden ția mai multe roluri cu
privilegii necesare diferite.
118
119 Anexa 1 Bibliografie
[AB06] M.J. Atallah, M. Blanton, Key management for non-tree access hierarchies ,
Symposium on Access Control Models and Technologies , March 2006, pp.
11-18, ISBN: 1-5959-353-0
[AS00] G. Ahn, R. Sandhu, Role-based authorization constraints specification, ACM
Transaction Information Systems, Sect. 3, 4, Nov. 2 000, pp. 207-226, ISSN:
1094-9224
[AW 103] K. Alghathbar, D. Wijesekera, AuthUML: A Three-phased Framework to
model Secure Use Cases, Proceedings of the Formal Methods în Security
Engineering Workshops, (FMSE’03), Oct. 2003, pp. 77 -86, ISBN: 4790-
7688
[AW 203] K. Alghathbar, D. Wijesekera, Consistent and Complete Access Control
Policies in Use Cases, Proceedings of UML 2003, LNCS, 2003
[AW05] V. Atluri, J. Wagner, Supporting Conditional Delegation in Secure Workflo w
Management Systems, SACMAT’05 , Iunie, 2005, ISBN: 1-59593-045-0
[B75] K. J. Biba, Integrity consideration for secur e computer systems, Technical
Report MTR-3153 , MITRE Corporation, Bedford, MA, April 1975
[B95] J. Barkley, Implementing role based access control using object technology,
Proceedings of the ACM Workshop of Role Based Acces s Control,
November 1995, pp. 20-es., ISBN: 0-89791-759-6
[B97] L. Bartz, hyperDRIVE: Leveraging LDAP to implement RBAC on th e web,
Proceedings of the ACM Workshop of Role Based Acces s Control, 1997,
pp.69-74, ISBN: 0-89791-985-8
[B05] K. Beznosov, Future direction of access control models, architec tures, and
technologies , Proceedings of the tenth ACM symposium on Access control
model and technologies, SACMAT’0 5, Iunie, 2005, pp. 48, ISBN: 1-59593-
045-0
[B06] C. Bibere, Dezvoltarea comer țului realizat pe Internet, Teza de doctorat , 2006,
http://www.cnaa.acad.md/thesis/5670/
[B +91] G. Booch, et all, Object-Oriented Design With Applications ,
Benjamin/Cummings, 1991
[BBF00] E. Bertino, P. A. Bonatti, E. Ferrari, TRBAC: a temporal role-based access
control model, Proceedings of the Fifth ACM Workshop on Role-Base d
Access Control (RBAC’00), pp 21–30, 2000, ISBN: 897 0-6549.
[BBF01] E. Bertino, P. A. Bonatti, E. Ferrari, TRBAC: A temporal rolebased access
control model , ACM Transactions on Information and System Securi ty
(TISSEC), pp. 191–233, August 2001, ISSN: 1994-9224 .
[BCD +05] E. Bertino, B. Catania, M. L. Damiani, P. Perla sca, GEO-RBAC: a
spatially aware RBAC , Proceedings of the tenth ACM symposium on Access
control models and technologies , June 2005, pp. 29-37, ISBN: 1-59593-045-
0
[BDL03] D. Basin, J. Doser, T. Lodderstedt, Model driven security for process-
oriented systems, Proceedings of the eight ACM symposium on Access
control model and technologies, SACMAT ’03, June 20 03, pp.100-109,
ISBN: 1-58113-681-1
120 [BFA97] E. Bertino, E. Ferrari, V. Atluri, A flexible model supporting the
specification and enforcement of role-based authori zation in workflow
management systems , Proceedings of the Second ACM Workshop on Role-
Based Access Control (RBAC’97), pp. 1–12, 1997, ISB N: 0-89791-985-8
[BFA99] E. Bertino, E. Ferrari, V. Atluri , The specification and enforcement of
authorisation constraints in workflow management sy stems , ACM
Transactions on Information Systems Security, Novem ber 1999, pp. 65-104,
ISBN: 1094-9224
[BHM06] S. Brlek, S. Hamadou, J. Mullins, Some Remarks on the Certificates
Registration on the Electronic Commerce Protocol SE T , Advanced
International Conference on Telecommunications and International
Conference on Internet and Web Applications and Ser vices, February 2006,
pp. 119, ISBN: 1094-9225
[BJS96] E. Bertino, S. Jajodia, P. Samarati, Supporting multiple access control
policies in database systems , IEEE Symposium on Security and Privacy
(SSP’96), 1996, pp. 94-107, ISBN: 0-8186-7417-2
[BK03] J. Biskup, Y. Karabulut, A hybrid pki model – Application to secure
mediation, Research Directions în Data and Application Securi ty, 2003,
www.informatik.uni-dortmund.de/uploads/tx_ls6ext/Bi skup_
Karabulut_2002a.pdf
[BL76] D. E. Bell, L. J. LaPadula, Secure computer systems: Unified exposition and
Multics interpretation , Technical Report MTR-2997, The MITRE
Corporation, July 1975, www.csrc.nist.gov/publicati ons/history/bell76.pdf
[BLN82] A.D. Birrell, R. Levin, R. M. Needham, M.D. Schroeder, Grapevine: An
exercise în distributed computing, Communication of the ACM, pp. 260-274,
April 1982, ISSN: 0001-0782
[BM +07] G. Booch, R. Mansimchuck and all., Object Analysis and Design with
Applications , Object Software Engineering, 3 rd edition, 2007, ISBN-13: 978-
0201895513
[BMY02] J. Bacon, K. Moody, W. Yao, A model of OASIS role-based access control
and its support for active security, ACM Transactions on Information and
System Security (TISSEC), pp. 492–540, November 200 2, ISSN: 1094-9224
[BN89] D. Brewer, M. Nash, The Chinese wall security policy , Proceedings of th
Symposium on Security and Privacy, IEEE Press, pp 2 15-228, 1989
[BPM02] G. Bella, L. Paulson, F. Massacci, Cryptographic protocols: The
verification of an industrial payment protocol: the SET purchase phase ,
Proceedings of the 9 th ACM conference on Computer and communications
security, November 2002, pp. 12-22, ISBN: 1-58113-6 12-9
[BS 100] E. Barka, R. Sandhu, Framework for role-based delegation models , Sixteenth
Annual Computer Security Applications Conference, N ew Orleans,
Louisiana, December 2000, Digital ID: 10.1109/ACSAC .2000.898870.
[BS 200] E. Barka, R. Sandhu, A role-based delegation model and some extensions ,
Twenty-third National Information Systems Security Conference, Baltimore,
MD, October 2000,
www.csrc.nist.gov/nissc/2000/proceedings/papers/021 slide.pdf
[BW04] J. Biskup, S. Wortmann, Towards a credential-based implementation of
compound access control policies, Proceedings of the ninth ACM
symposium on Access control models and technologies , June 2004, pp. 31-
40, ISBN: 1-58113-872-5
121 [C89] S.K. Card, Human factors and artificial intelligence, Intelligent Interfaces
Theory, Research and Design, pp 27-41, New York, 19 89
[C03] D. Clark, Economics and the Design of Open Systems , IEEE Internet
Computing, March 2003, pp. 94-96
[CK96] A.O. Freier, P.Carlton, P. Kocher, The SSL Protocol version 3.0 , 1996,
http://ieeexplore.ieee.org/iel5/7739/21247/00985877 .pdf
[CLS +01] M. J. Covington, W. Long, S. Srinivasan, Anind K. Dev, Mustaque
Ahamad, G. D. Abowd, Securing context-aware applications using
environment roles , Sixth ACM Symposium on Access Control Models and
Technologies (SACMAT’01), pp. 10–20, 2001, ISBN: 1- 58113-350-2.
[CR06] S. Chakraborty, I. Ray, TrustBAC: integrating trust relationships into the
RBAC model for access control in open systems , Proceedings of the eleventh
ACM symposium on Access control models and technolo gies SACMAT '06 ,
June 2006, pp. 49-58, ISBN:1-59593-353-0
[CW87] D. Clark, D. Wilson, A comparison of commercial and military computer
security policies , Proceedings of th Symposium on Security and Priva cy,
IEEE Press, pp. 184-194, 1987, ISBN: 10-1109
[D02] N. C. Damianou, A Policy Framework for Manage ment of Distributed
Systems, PhD thesis, Department of Computing, Imper ial College of
Science, Technology and Medicine, University of Lon don, 2002.
[DD +04] T. Doan, S. Demurjian and all., MAC and UML for secure software design,
Proceedings of the Formal Methods în Security Engin eering Workshops,
(FMSE’04), Oct. 2004, pp. 75-85, ISBN:1-58113-971-3
[DDT +04] T. Doan, S. Demurjian, T. C. Ting, A. Ketterl, Security & analysis II: MAC
and UML for secure software design, Proceedings of the 2004 ACM
workshop on Formal methods -în security engineering , October 2004, pp. 75-
85, ISBN:1-58113-971-3
[DK01] Q. Dai, R. Kauffman, Business Models for Internet based E-Procurement
Systems and B2B Electronic Markets: An Exploratory Assessment , 34th
Annual Hawaii International Conference on System Sc iences – Volume 7,
January 2001, pp. 704
[DDL +01] N. Damianou, N. Dulay, E. Lupu, M. Sloman, The Ponder policy
specification language , Policies for Distributed Systems and Networks,
International Workshop (POLICY’01), Bristol, UK, pp . 18–38, 2001 [EE01]
The electronics industry supply chain: who does wha t?, 38 th Conference of
Design Automation , 2001, www.doc.ic.ac.uk/~mss/Papers/Ponder-Policy01V5.pdf
[EF99] Robert J. Ellison, David A. Fisher, et all, Survivability: Protecting Your
Critical Systems, IEEE Internet Computing, November1999, pp. 55-63,
Digital Object Identifier 10.1109/4236.807008
[ES99] P. Epstein, R. Shandu , Towards a UML Based Approach to Role Engineering ,
Proceedings of the 4 th ACM workshop on Role-based Access Control, 1999,
pp. 135-143, ISBN:1-58113-180-1
[F00] C. A. Fregly, Techniques for Optimizing Web Site Development and Runtime
Characteristics, Java Report, November 2000,
http://www.adtmag.com/java/articleold.aspx?id=1614
[FBK98] D. Ferraiolo, J. Barkley, D. Kuhn, A role-based access control model and
reference implementation within a corporate intrane t , ACM Transaction on
Information and System security, 2, February 1998, pp.34-64, ISSN:1094-
9224
122 [FCK95] D. Ferraiolo, J. Cugini, R. Kuhn, Role-based access control: Features and
motivations, Proceedings of Annual Computer Security Application s
Conference, IEEE Press, 1995, hissa.ncsl.nist.gov/r bac/newpaper/rbac.html
[FGL95] D. Ferraiolo, D. Gilbert, N. Lynch, An examination of federal and
commercial access control policy needs, Proceedings of the NIST_NSA
National (USA) Computer Security Conference, pp. 10 7-116, 1995,
csrc.nist.gov/rbac/sandhu96.pdf
[FK92] D. Ferraiolo, R. Kuhn, Role-based Access Control, Proceedings of 15 th NIST-
NCSC National Computer Security Conference, Gaither sburg, 1992, pp.554-
563, csrc.nist.gov/rbac/
[FL00] S. Fong, C. Se-Leng, Modeling personnel and roles for electronic commerce
retail, Proceedings of the 2000 ACM SIGCPR conference on Co mputer
personnel research , April 2000, pp. 45-53, ISBN:1-58113-212-X
[FSG01] David F. Ferraiolo, Ravi Sandhu , Serban Ga vrila , D. Richard Kuhn ,
Ramaswamy Chandramouli, Proposed NIST standard for role-based access
control , ACM Transactions on Information and System Securi ty (TISSEC),
v.4 n.3, pp.224-274, August 2001 (1), ISSN:1094-922 4
[FSN05] J. Froberg, K. Sandstrom, C. Norstrom, Bussiness situation reflected in
automotive electronic architectures: analysis of fo ur commercial cases ,
Proceedings of the 2005 workshop on Software engine ering for automotive
systems, 2005, ISBN:1-59593-128-7
[G96] L. Giuri, Role-based access control: a natural approach , Proceedings of the
First ACM Workshop on Role-Based Access Control (RB AC’95), pp. II–33–
37, 1996, ISBN:0-89791-759-6
[G98] L. Giuri, Role-based access control in Java , Proceedings of the Third ACM
Workshop on Role-Based Access Control (RBAC’98), pp . 91–100, 1998,
ISBN:1-58113-113-5
[G99] L. Giuri, Role-base access control on the web using java , Proceedings of the
ACM Workshop on Role-Based Access Control, 1999, pp . 11-18, ISBN:1-
58113-180-1
[G00] A. Gupta, Automating Any-to-Any Content Exchange, IEEE IT Professional,
Sept. 2000, pp. 52-54, Digital Object Identifier 10.1109/6294.877499
[GD75] G. S. Graham, P.J. Denning, Protection – principles and practice ,
Procedeengs of the fifth ACM symposium on Operating systems principles,
May 1975, pp. 14-24, ISSN:0163-5980
[GGF98] V.D. Gligor, S.I.Gavrila, D.F. Ferraiolo, On the formal definition of
separation-of-duty policies and their composition , Proceedings of the
Symposium on Security and Privacy, IEEE Press, Los Alamitos, California,
1998,
www.glue.umd.edu/afs/glue.umd.edu/home/enee/faculty /gligor/pub/oak98.ps
[GGK +89] M. Gasser, A. Goldstein, C. Kaufman, B. Lampson , The Digital
distributed system security architecture , Proceedings of the 1989 National
Computer Security Conference, pp. 305-319, October 1989,
research.microsoft.com/Lampson/41-DigitalDSSA/41- DigitalDSSA.htm
[GHS95] D. Georgakopoulos, M. Hornik, A. Sheth, An overview of Workflow
Management: From Process Modeling to Workflow Auto mation
Infrastructure, Distributed and Parallel Databases, pp 119-153, 19 95,
ISSN:0926-8782
[GI96] L. Giuri, P. Iglio, A formal model for role based access control with
constraints , Proceedings of the Computer Security Foundations Workshop,
123 IEEE Press, Los Alamitos, California, pp.136-145, 1 996, Digital Object
Identifier 10.1109/CSFW.1996.503698
[GI97] L. Giuri, P. Iglio, Role templates for content-based access control ,
Proceedings of the Second ACM Workshop on Role-Base d Access Control
(RBAC’97), pp. 153–159, 1997, ISBN:0-89791-985-8
[GM90] M. Gasser, E. McDermott, An architecture for practical delegation in a
distributed system , Proceedings of the 1990 IEEE Symposium on Securi ty
and Privacy, pp. 20-30, May 1990, ISBN: 63835-X
[GMS94] C. H. Goh, S. E. Madnick, M. D. Siegel, Context interchange: overcoming
the challenges of large-scale interoperable databas e systems in a dynamic
environment , Proceedings of the third International Conference on
Information and Knowledge Management, pp. 337–346, ACM Press, 1994,
ISBN:0-89791-674-3
[HA99] Wei-Kuang Huang, V. Atluri, SecureFlow: a secure Web-enabled workflow
management system , Proceedings of the Fourth ACM Workshop on Role-
Based Access Control (RBAC’99), pp. 83–94, 1999, IS BN: 1-58113-180-1
[HBP +99] J. Hands, M. Bessonov, A. Patel, R. Smith, An Inclusive Architecture for
Electronic Brockerage , 32 nd Annual Hawaii International on System
Sciences – Volume 8, January 1999, pp. 8025, Digita l Object Identifier
10.1109/HICSS.1999.773056
[HD95] M.Y.Hu, S.A. Demurjian, T.C. Ting, User-Role based Security în the ADAM
Object-Oriented Design and Analyses Environment , Database Security VIII:
Status and Prospects, 1995, pp. 333-348, ISBN:0-897 91-808-8
[HH02] O. Henfridsson, H. Holmstrom, Developing e-commerce in internetworked
organizations: a case of customer involvment throug hout the computer
gaming value chain , ACM SIGMIS, 2002, pp. 38-50, ISSN:0095-0033
[HL04] Horst F. Wedde, Mario Lischka, Modular authorization and administration ,
ACM Transactions on Information and System Security (TISSEC), Volume
7 Issue 3, August 2004, pp. 363-391, ISSN:1094-9224
[HTTP 103] Platform for Privacy Preferences – http://www.w3.org.P3P/ , 2003
[HTTP 203] Critical Foundations – http://www.pccip.gov , 2003
[HTTP1] Petri Networks: Definition and basic ideas , Examples, Reference,
http://staff.um.edu.mt/jskl1/petri.html
[HTTP2] OASIS. Assertion and Protocol for the OASIS Securit y Assertion Markup
Language (SAML) , Committee Specification 01, Organization for the
Advancement of Structured Information Standard, Oct ober 2002,
http://www.oasis-open.org/committees/security/
[HTTP3] Limbajul Alloy , http://web.mit.edu/~rseater/www/tutorial2/alloy-
tutorial.html
[HTTP4] Standardul RBAC dezvoltat de NIST : http://csrc.nist.gov/rbac/
[HTTP5] Componente software RBAC (RBAC for UNIX/POSIX/Linux and RBAC for
Windows NT) , http://csrc.nist.gov/rbac/
[HTTP06] DACS 2006: The Distributed Access Control System, http://dacs.dss.ca/
[J98] W.A. Jansen, Inheritance Properties of Role Hierarchies , 21st National
Information Systems Security Conference, October, 1 998,
http://csrc.nist.gov/nissc/1998/papers.html
[J99] T. Jaeger, On the increasing importance of constraints , Proceedings of the
Fourth ACM Workshop on Role-Based Access Control (R BAC’99), pp. 33–
42, 1999, ISBN:1-58113-180-1
124 [J02] J. Jurgens, Principles for Secure System Design , Ph.d. dissertation. Oxford
University Computing Laboratory, Oxford University, 2002
[J05] J. Jurgens, Security: Sound methods and effective tools for mod el-based security
engineering with UML , Proceedings of the 27 th international conference on
Software engineering ICSE ‘05, Mai 2005, pp. 322-33 1, ISBN:1-59593-963-
2
[J +92] I. Jacobson, et all, Object-Oriented Software Engineering: A Use Case Dr iven
Approach , Addison-Wesley, 1992
[J93] D.Jonscher, Extending Access Control with Duties – Realized by Active
Mechanisms , Database Security VI: Status and Prospects, 1993 , pp. 91-111,
ISBN:0-444-89889-1
[JSS97] S. Jajodia, P. Samarati, V. S. Subrahmanian , A logical language for
expressing authorizations, Proceedings of IEEE Symposium on Security and
Privacy (SSP’97), pp. 3142, 1997, ISSN:1094-9224
[JSS +97] S. Jajodia, P. Samarati, V. Subrahmanian, E. Be rtino, A unified framework
for enforcing multiple access control policies , SIGMOD’97, pp. 474–485,
1997, ISSN:0163-5808
[JSS +01] S. Jajodia, P. Samarati, M. L. Sapino, V. S. Su brahmanian, Flexible support
for multiple access control policies , ACM Transactions on Database Systems
(TODS’01), pp. 214–260, 2001, ISSN:0362-5915
[JT00] T. Jaeger, J. Tidswell, Rebuttal to the NIST RBAC model proposal,
Proceedings of the Fifth ACM Workshop on Role-Based Access Control, pp.
65-66, July 2000, ISBN:1-58113-259-X
[K94] M. Kempe, A framework for the blackboard model , 1994,
http://citeseer.ist.psu.edu/127277.html
[K 197] R. Kuhn, Mutual exclusion as a means of implementing separat ion of duty
requirements în role based access control systems , Proceedings of the
Second ACM Workshop on Role Based Access Control, p p. 23-30, 1997,
ISBN:0-89791-985-8
[K 297] D.R. Kuhn, Mutual Exclusion of Roles as a Means of Implementin g
Separation of Duty in Role Based Access Control Sys tems , Second ACM
Workshop on Role Based Access Control, 1997, pp. 23 -30, ISBN:0-89791-
985-8
[KA98] S.Kent, R. Atkinson, Security Architecture for the Internet Protocol , RFC
2401, Nov. 1998, http://www.ietf.org/rfc/rfc2401.tx t
[KH02] C. Joncheng Kuo, Polar Humenn, Session 4: Web service applications:
Dynamically authorized role-based access control fo r secure distributed
computation, Proceedings of the 2002 ACM workshop on XML securi ty ,
November 2002, pp.97-103, ISBN:1-58113-632-3
[KS03] M. A. Al-Kahtani, R. Sandhu, Induced role hierarchies with attribute-based
RBAC , Proceedings of the Eighth ACM Symposium on Access Control
Models and Technologies (SACMAT’03), pp. 142–148, A CM Press, 2003,
ISBN:1-58113-681-1
[L71] B. Lampson, Protection, Proceedings of the Fi fth Annual Princeton Conference
on Information Sciences and Systems, pp 437–443, Pr inceton University,
1971
[L89] J.W. Lloyd, Foundation of Logic Programming , Springer-Verlag, 1989,
http://prism.cs.umd.edu/papers/banquet89/banquet89. html
[L97] P. Lawrence, Workflow Handbook 1997 , Workflow Management Coalition ,
Jan. 1997, ISBN-10: 0471969478
125 [L98] E. Lupu, A Role-Based Framework for Distributed Systems Mana gement , PhD
thesis, Department of Computing, Imperial College o f Science, Technology
and Medicine, University of London, 1998.
[L05] J. Linn, Technology and Web User Data Privacy: A Survey of R iskjs and
Countermeasures , IEEE Security and Privacy, 2005, pp. 52-58
[LL98] L. Lefebvre, E. Lefebvre, The virtual economy as an emerging paradigm , 31 st
Annual Hawaii International Conference on System Sc iences, Volume 6,
1998, pp. 33, ISBN: 0-8186-8255-8
[LPL +03] M. Lorch, S. Proctor, R. Lepro, D. Kafura, First experiences using XACML
for access control in distributed systems , Workshop in XML Security, 2003,
pp. 25-37, ISBN:1-58113-777-X
[LS97] E. Lupu, M. Sloman, Reconciling role based management and role based
access control , Proceedings of the Second ACM Workshop on Role-Ba sed
Access Control (RBAC’97), pp. 135–141, 1997 ISBN:0- 89791-985-8
[LS99] E. Lupu, M. Sloman, Conflicts in policy-based distributed systems
management , IEEE Transactions on Software Engineering, pp. 85 2–869,
1999, Digital Object Identifier 10.1109/32.824414
[M +92] D.L. Maulsby and all, Inferring graphical procedures: The complete
metamouse , Human-Computer Interaction, pp 47-90, 1992,
www.srs4702.forprod.vt.edu/pubsubj/pdf/03t3.pdf
[M94] S. Mullender, Distributed Systems , ACM Press New York, ISBN 0-201-62427-
3, 1994
[M95] P.V. McMahon, SESAME V2 Public Key and Authorization Extensions t o
Kerberos, Proceedings of the 1995 Symposium on Network and Di stributed
System Security , pp 114-131, February 1995
[M98] J.D. Moffet, Control principles and role hierarchies , Proceedings of the Third
ACM Workshop on Role-Based Access Control, Oct. 199 8, pp. 63-69,
ISBN:1-58113-113-5
[M99] C. Metz – AAA Protocol: Authentication, Authorization and Acc ounting
for the Internet, IEEE Internet Computing, 1999, pp. 75-79, ISBN: 423 6-
807015
[MN88] S.P. Miller, B.C. Neuman, J. I. Schiller, J. H. Saltzer, Section E.2.1: Kerberos
Authentication and Authorization System , Project Athena Technical Plan,
MIT Project Athena, Cambridge, Massachusetts, Octob er 1988,
http://web.mit.edu/Kerberos/papers.html
[N93] B. C. Neuman, Proxy-based authorization and accounting for distri buted
systems, Proceedings of the 13 th International Conference în Distributed
Computing Systems, pp 283-291, May 1993, ISBN: 0-81 86-3770-6
[NC00] SangYeob Na, SuhHyun Cheon, Role delegation in role-based access
control , Proceedings of the Fifth ACM Workshop on Role-Bas ed Access
Control (RBAC’00), pp. 39–44, 2000, ISBN:1-58113-25 9-X
[NO94] M. Nyanchama, S. Osborn, Access Rights Administration în Role-Based
Security Systems, Database Security VIII: Status and Prospects, 1994, pp. 37-
56
[NO95] M. Nyanchama, S. Osborn , The role graph model , Proceedings of the First
ACM Workshop on Role-Based Access Control (RBAC’95) , pp. 25–31,
1995, ISSN:1094-9224
[NO99] M. Nyanchama, S. Osborn, The role graph model and conflict of interest ,
ACM Transactions on Information and System Security (TISSEC), pp. 3–33,
1999, ISSN:1094-9224
126 [NS02] G. Neumann, M. Strembeck, A scenario-driven role engineering process for
functional rbac roles , Seventh ACM Symposium on Access Control Models
and Technologies (SACMAT’02), p. 33–42, ACM Press, 2002, ISBN:1-
58113-496-7
[O97] S. Osborn, Mandatory access control and role-based access cont rol revisited ,
Proceedings of the Second ACM Workshop on Role-Base d Access Control
(RBAC’97), pp. 31–40, 1997, ISBN:0-89791-985-8
[O00] M. Ordean, An application framework for e-commerce platforms , e-Commerce
Simpozion, Bilateral cooperation Romania-Croatia, C luj-Napoca, oct. 2000
[O02] S. Osborn, Information flow analysis of an rbac system , Seventh ACM
Symposium on Access Control Models and Technologies (SACMAT’02),
pp. 163–168, ISBN:1-58113-496-7
[OG05] M.Ordean , D.Gorgan, Role-based authorization using graphical user
interfaces in distributed systems, ROCHI Cluj-Napoca Romania, September
2005, ISBN 973-7973-24-0
[OG 107] M. Ordean, D. Gorgan, "FORMAL DEFINITION OF SCAR-ACE ROLE-
BASED ACCESS CONTROL MODEL" , Proceedings CSCS-16, 16th
International Conference on Control System and Comp uter Science, 22-25
May 2007, Bucharest, Vol. 2, pp 155-159, ISBN:978-9 73-718-743-7
[OG 207] M. Ordean, D. Gorgan, RBAC and SCAR-ACE Role Based Access Models ,
VIPSI 2007 Venice, International Conferences on Adv ances in the Internet,
Processing, Systems, and Interdisciplinary Research , March 19-22, 2007,
Italy, Book of Abstracts, ISBN 86-7466-117-3, pp. 1 2
[OGI05] M. Ordean, D. Gorgan, I. Ignat, Security Tiers Specification by RBAC and
UML, Scientific Journal of Automation Computers Applied Mathematics
(ACAM), vol. 14, 2005, no 1, ISSN 1221-437X, pp. 43 -50
[OMG1] OMG. ptc/01-06-17: CSIv2 proposed finalized specification , Non-change
barred proposed finalized specification of CSIv2 , http://www.omg.org/cgi-
bin/apps/doclist.pl
[OMG2] OMG. formal/02-06-01 (CORBA 3.0 version) http://www.omg.org/cgi-
bin/doc?formal/02-06-01
[OMG3] OMG. Authorization Token Layer Acquisition Service Speci fication , Object
management Group, October 2001, http://cgi.omg.org/ cgi-bin/doc?ptc/2001-
10-22
[P93] R. Puerta, The study of models of intelligent interfaces, International
Conference on Intelligent User Interfaces, pp: 71 – 78, 1993, ISBN: 0-89791-
556-9
[PP95] T. Parker, D. Pinkas, “SESAME V4 – Overview ”, December 1995,
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt /overview.txt
[PS00] J. Park, R. Sandhu, Secure Cookies on the Web , IEEE Internet Computing,
July 2000, pp. 36-44, Digital Object Identifier 1 0.1109/4236.865084
[PS05] S. Park, N. Suresh, An investigation of roles of electronic marketplace in the
supply chain , Procedeengs of the 38 th Annual Hawaii International
Conference on System Sciences, 2005, pp. 161b, Digi tal Object Identifier
10.1109/HICSS.2005.93
[PSA01] Joon S. Park, Ravi Sandhu, Gail-Joon Ahn, Role-based access control on the
web , ACM Transactions on Information and System Secur ity (TISSEC),
February 2001, pp. 37-71, ISSN:1094-9224
[R +91] J. Rumbaugh, et all, Object-Oriented Modeling and Design , Prentice-Hall,
1991
127 [R +03] I. Ray, et all, Using Parametrized UML to Specify and Compose Acces s
Control Models, Proceedings of the 6 th IFIP Working Conference on
Integrity & Internal Control în Info. Systems, 2003 , ISBN:1-58113-872-5
[RK00] P. Ratnasingham, K. Kumar, Trading partner trust in electronic commerce
participation , Proceedings of the 21 st international concerence on
Information systems, December 2000, pp 544-552, ISB N:ICIS2000-X
[S88] K. R. Sollins, Cascaded Authentication , Proceedings of the 1988 IEEE
Symposium on Security and Privacy, IEEE Computer So ciety, 1988, pp. 156,
ISBN: 0-8186-0850-1
[S92] R. Sandhu, The typed access matrix model , Proceedings of the Eleventh IEEE
Symposium on Security and Privacy (SSP’92), pp. 122 –136, 1992, Digital
Object Identifier 10.1109/RISP.1992.213266
[S93] R. Sandhu, Lattice-based access control models , IEEE Computer, 26(11), pp.
9–19, 1993, ISSN: 0018-9162
[S94] M. Sloman, Policy driven management for distributed systems , Network and
Systems Management, pp. 333–360, 1994, ISBN:1-59593 -116-3
[S96] R. Sandhu, Rationale for the RBAC96 family of access control m odels ,
Symposium on Access Control Models and Technologies , 1996, Article no.
9, ISBN:0-89791-759-6
[S00] R. Sandhu, Engineering authority and trust in cyberspace: the OM-AM and
RBAC way , Proceedings of the Fifth ACM Workshop on Role-Bas ed Access
Control (RBAC’00), pp. 111–119, 2000, ISBN:1-58113- 259-X
[SA00] M. Shin, G. Ahn, UML-Based Representation on Role-based Access Contr ol ,
Proceedings of the 9 th IEEE workshop on Enabling Technologies:
Infrastructure for Collaborative Enterprises, 2000, Digital Object Identifier
10.1109/ENABL.2000.883728
[SBC +97] R. Sandhu, V. Bhamidipati, E. Coyne, S. Ganta, C. Youman, The
ARBAC97 model for role-based administration of role s: preliminary
description and outline , Proceedings of the Second ACM Workshop on Role-
Based Access Control (RBAC’97), pp. 41–50, 1997, IS BN:0-89791-985-8
[SBM98] R. Sandhu, V. Bhamidipati, Q. Munawer, The ARBAC97 model for role-
based administration of roles , ACM Transactions. Inf. Syst. Security, 1998,
pp. 105-135, ISSN:1094-9224
[SC96] R. Sandhu, F. Chen, Constraints for role-based access control , 1 st ACM
Workshop on Role-based access control, 1996, ISBN:1 -58113-681-1
[SC01] P. Samarati, S. Capitani, Access control – policies, models and mechanisms ,
Foundations of Security Analysis and Design, Octobe r 2001, pp 137-196,
www.springerlink.com/index/80wrewj7j1a716wb.pdf
[SCH +96] R. Sandhu, E.Coyne, H. Feinstein, C. Youman, Role-based access control
models, IEEE Computer, pp 38-47, 1996, csrc.nist.gov/rbac/ sandhu96.pdf
[SH97] Hans Schuster, Petra Heinl, A workflow data distribution strategy for scalable
workflow management systems , Proceedings of the 1997 ACM symposium
on applied computing, April 1997, pp. 174-176, ISBN :0-89791-850-9
[SFK00] R. Sandhu, D. Ferraiaolo, R. Kuhn, The NIST model for role-based access
control: Towards a unified standard , Proceedings of the Fifth ACM
Workshop on Role-Based Access Control , July 2000, pp. 47-63, ISSN:1094-
9224
[SM00] S.H. von Solms, I. van der Merwe, The Mangement of Computer Security
Profile, 2000
128 [SL98] B. Schmid, M. Lindemann, Elements of a Reference Model for Electronic
Market , 31 st Annual Hawaii International Conference on System Sc iences –
Volume 4, January 1998, pp. 0193, Digital Object Id entifier
10.1109/HICSS.1998.655275
[SM 102] A. Schaad, J. Moffett, Delegation of obligations , Third IEEE International
Workshop on Policies for Distributed Systems and Ne tworks (POLICY’02),
pp. 25–35, 2002, Digital Object Identifier 10.1109/ POLICY.2002.1011290
[SM 202] A. Schaad, Jonathan D. Moffett , A lightweight approach to specification and
analysis of role-based access control extensions, Symposium on Access
Control Models and Technologies, pp. 13-22, 2002, I SBN:1-58113-496-7
[SRJ01] P. Samarati, M. K. Reiter, S. Jajodia, An authorization model for a public key
management service , ACM Transactions on Information and System Securi ty
(TISSEC), pp. 453–482, 2001, ISSN:1094-9224
[SZ83] R. Simon, R. Zurko, Separation of duty în role based access control
environments, Proceedings of New Security, Paradigms Workshop, S ept.
1997, pp. 183, ISSN:0018-8670
[T05] B. Travica, Virtual organizations and electronic commerce , ACM SIGMIS,
2005, pp. 45-68, ISSN:0095-0033
[T97] R. K. Thomas, Team-based access control (TMAC): a primitive for a pplying
role-based access controls in collaborative environ ments , Proceedings of the
Second ACM Workshop on Role-Based Access Control (R BAC’97), pp. 13–
19, 1997, ISBN:0-89791-985-8
[TAP +05] W. Tolone, G. Ahn, T. Pai, S. Hong, Access control in collaborative
systems , ACM Computing Surveys (CSUR), March 2005, pp. 91- 100,
ISSN:0360-0300
[TC97] Z. Tari, S. Chan, A role based access control for intranet security, IEEE
Internet Computing, September/October 1997, pp. 24- 34, Digital Object
Identifier 10.1109/4236.623965
[TL04] M. V. Tripunitara, N. Li, Comparing the expressive power of access control
models, Proceedings of the 11th ACM conference on Computer and
communications security, October 2004, pp. 62-71, ISBN:1-58113-961-6
[TS97] R. K. Thomas, R. Sandhu, Task-based Authorization Controls (TBAC): A
family of models for active and enterprise-oriented authorization
management , Proceedings of the IFIP WG 11.3 Workshop on Datab ase
Security, pp. 166–181, August 1997, ISBN:0-412-8209 0-0
[TS98] G. Winfield Treese, L. C. Stewart, Designing Systems for Internet Commerce ,
Addison-Wesley Longman Publishing Co ., 1998, ISBN: 0-202-57167-6
[TS02] A.S. Tanenbaum, M. Steen, Distributed Systems – Principles and Paradigms ,
Prentice Hall, NJ, September 2002
[TT02] Y. Tan, W. Thoen, Formal Aspects of a Generic Model of Trust for Elec tronic
Commerce , Decision Support System, Volume 33, July 2002, pp . 233-246
[W96] L. Wang, A framework for map recognition based on blackboard model , 1996,
http://citeseer.ist.psu.edu/11673.html
[WK05] Jacques Wainer, Akhil Kumar, A fine-grained, controllable, user-to-user
delegation method in RBAC, Proceedings of the tenth ACM symposium on
Access control models and technologies, June 2005, pp. 59-66, ISBN:1-
59593-045-0
[WL98] T.Y.C. Woo, S.S. Lam, Designing a Distributed Authorization Service ,
Proceedings of IEEE INFOCOM’98, March 1998, ISBN: 0 -7803-4383-2
129 [YD05] F. Yi, L. Diao, E-commerce models, structure, mechanisms, globaliza tion
and strategy: Electronic market and operating inter mediary , Proceedings of
the 7 th international conference on Electronic commerce, I CEC, 2005, pp. 1-
5, ISBN:1-59593-112-0
[YLS96] N. Yialelis, E. Lupu, M. Sloman, Role based security for distributed object
systems , Proceedings of the Fifth Workshops on Enabling Te chnologies:
Infrastructure for Collaborating Enterprises (WET-I CE’96), pp. 80–85, 1996,
ISBN:0-8186-7445-8
[ZAC01] L. Zhang, Gail-Joon Ahn, Bei-Tseng Chu, A rule-based framework for role
based delegation , Sixth ACM Symposium on Access Control Models and
Technologies (SACMAT’01), pp. 153–162, 2001, ISSN:1 094-9224
[ZK98] J. Leon Zhao, Akhil Kumar, Data management issues for large scale,
distributed workflow systems on the Internet , ACM SIGMIS
Database, Volume 29 Issue 4, 1998, pp. 22-32, ISSN: 0095-0033
[ZM90] S. Zdonik, D. Maier, Fundamentals of Object-Oriented Database , Readings
in Object-Oriented Database Systems, 1990,
www.toa.com/pub/reading_list_article.txt
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Teza de doctorat [621280] (ID: 621280)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.