Mentinerea conturilor utilizatorilor

Mentinerea conturilor utilizatorilor

Fara o interfata in care sa se implementeze schimbarile pentru utilizatori, roluri, privilegii, mentinerea scripturilor pentru acestea poate fi foarte obositoare. Sunt necesare aplicatii care sa usureze controlul utilizatorilor si privilegiilor lor, si aplicatii care sa pastreze informatii referitoare la schimbarile facute.

1. Cerinte pentru designul aplicatiei

Ce se doreste de la aceasta aplicatie?

• Aplicatia trebuie sa permita crearea si mentenanta conturilor de utilizatori.
• Trebuie sa permita crearea rolurilor si acordarea sau revocarea privilegiilor pentru aceste roluri.
• Trebuie sa permita ca mi multe roluri sa fie acordate unui utilizator.
• Cand un rol este acordat, aplicatia trebuie sa permita utilizatorului security sa hotarasca daca acel rol va fi unul predefinit.
• In procesul de acordare a rolurilor, rolurile acordate anterior trebuie pastrate, si acele care sunt predefinite trebuie sa ramana neschimbate.
• Aplicatia trebuie sa permita revederea acestor acordari.

2. Rularea aplicatiei

Acest formular pentru mentenanta securitatii a fost dezvoltat folosind produsul Oracle Developer. Acest formular functioneaza numai pentru utilizatori, roluri si privilegii de sistem.

Aceasta aplicatie foloseste tabele ale dictionarului de date si tabelul APP_ROLES. Acest tabel este unul creat si nu face parte din dictionarul de date. Acesta este singurul tabel folosit de catre formular al carui continut se poate modifica direct. Schimbarile in toate celelalte sectiuni ale formularului sunt realizate prin proceduri PL/SQL.

2.1. Fereastra initiala

In figura 1 reprezinta fereastra de start. Sunt trei sectiuni ale formularului: mentenanta utilizatorilor, mentenanta rolurilor, si acordarea rolurilor.

fig.1.

Primele doua campuri de sus sunt sectiunea pentru mentenanta utilizatorilor. Aici poate fi creat sau distrus un utilizator sau se poate schimba o parola. Asignarea spatiilor de tabel, temporara sau predefinita se realizeaza tot aici.

2.2. Selectarea sau crearea unui utilizator

Daca este introdus un nume de utilizator care nu exista, va aparea un mesaj la dreapta campului "User to create or modified". De exemplu, pentru un utilizator deja existent se poate introduce un nume in camp sau campul poate fi interogat. Daca campul este interogat, o fereastra va aparea in coltul din dreapta sus al formularului, ca in fig. 2

.

fig.2.

Aici se va alege numele de utilizator security. Apasand butonul OK acest nume se va muta in primul camp. In acest moment formularul afiseaza schimbari care indica daca acest utilizator exista si va arata ca in fig 3.

fig.3.

Dupa cum se observa, formularul arata ca utilizatorul exista, si apare un nou buton care permite distrugerea utilizatorului. Butonul care mai inainte se numea 'Create user', acum se numeste 'Change PASSWORD'. Blocul 'Available roles' se va popula cu toate rolurile existente in dictionarul de date. Cele doua casute de la dreapta campului cu roluri, indica statutul rolului in functie de utilizator. Poate fi acordat utilizatorului, poate fi rol implicit al utilizatorului, sau poate fi amandoua.

2.3. Acordarea rolurilor

Daca un rol nu este acordat utilizatorului, casuta 'Assigned to user?' va fi alba dar functionala cat timp casuta 'Default role?' va fi mata, indicand ca nu este activat. Aceasta este ilustrata in figura 4, unde cursorul se afla pe rolul CONNECT.

fig.4.

Casuta 'Default role?' este dezactivata deoarece daca un rol nu este acordat, nu poate fi facut rol predefinit. Daca se bifeaza casuta 'Assigned to user?', rolul curent este acordat utilizatorului si casuta 'Default role?' poate fi bifata. Daca se bifeaza casuta 'Default role?' rolul va fi rol implicit si se vor pastra toate rolurile implicite deoarece un utilizator poate avea mai mult de unul. Actiunea opusa apare in momentul in care se debifeaza o casuta care era bifata. Atunci rolul fie nu mai este predefinit, fie ii este luat utilizatorului.

Exista o limita in ceea ce priveste numarul de roluri pe care un user le poate avea o data. Aceasta limita este data de parametrul MAX_ENABLED_ROLES din fisierul INIT.ORA, si valoarea predefinita este de 20. Se pot asigna mai mult roluri decat valoarea maxima, dar atunci utilizatorul nu va mai putea sa se conecteze. Putini utilizatori au vreodata nevoie de mai mult de doua sau trei roluri predefinite; majoritatea nu au nevoie de mai mult de 5 sau 6 roluri in total.

2.4. Crearea de noi roluri

Se va crea rolul CDDEPTHD. Fereastra este accesata apasand butonul 'Manage roles'. Dupa introducerea numelui rolului, se poate opta pentru introducerea unei parole.

fig.5

Cand se introduce o parola pentru rol, casuta 'ADD TO ROLE TABLE' este activata. Daca se bifeaza aceasta casuta, fereastra va arata ca in figura 6. Se observa ca deja apar valorile tocmai create in tabel. Ferestrele sunt mate si valorile nu pot fi schimbate. Daca parola trebuie schimbata, aceasta se poate face mai tarziu folosind butonul 'ROLE SECURITY TABLE' . Cand o parola este schimbata o procedura PL/SQL se executa pentru a aplica schimbarea in dictionarul de date

2.5. Adaugarea privilegiilor de sistem rolurilor

Dupa intoarcerea la formularul initial, se navigheaza in setul 'Available roles' si se va seta rolul 'ADMIN_USR_ROLE'. Apasand butonul  'System privs', este afisat formularul din figura 7. Acesta afiseaza toate privilegiile de sistem disponibile. Acestea pot fi acordate sau luate rolului selectat prin bifarea sau debifarea casutelor din dreapta privilegiilor.

fig.7.

2.6. O problema de securitate

In cazul acestui formular pentru mentinerea securitatii utilizatorul are privilegiul sa acorde orice oricui dar nu poate sa isi acorde lui nimic. Acest utilizator nu are nici un privilegiu asupra nici-unui tabel din sistem in afara de tabelul APP ROLES, dar acest utilizator poate crea orice utilizator si sa acorde orice privilegiu acelui utilizator sau unuia deja existent. Din acest motiv, daca se foloseste o aplicatie ca cea din acest capitol, ar trebui sa fie o singura persoana care o foloseste. Daca se doreste mai mult de una, atunci ar trebui creat un alt utilizator security cu o alta parola.

I.5.2.7. Cum functioneaza?

Cum va functiona aplicatia de vreme ce majoritatea campurilor din formular sunt din tabelele dictionarului de date, si acestea nu se pot modifica direct cu comenzile SQL conventionale INSERT, UPDATE, sau DELETE. Schimbarile se realizeaza construind dinamic comenzi SQL folosind comenzile CREATE si ALTER USER. Dar aceasta poate cauza o problema cu PL/SQL. Fie programul:

SELECT deptno

FROM &1

GROUP BY deptnos;

Exista cel putin doua tabele in schema care contin coloana deptno, deci se poate rula programul tabelul fiind folosit ca argument 1. Acesta va fi unul din urmatoarele:

@shodepts emp

@shodepts dept

Din pacate nu se pot face acest tip de substitutii direct in PL/SQL. . In timp ce poti construi o comanda dinamica, abilitatea de a executa o comanda nu exista. Dar se poate realiza aceasta folosind pachetul DBMS_SQL primit o data ca instalarea bazei de date standard. Acest pachete permite construirea de comenzi SQL dinamice si executate in PL/SQL.

Cand aplicatia a fost dezvoltata initial, s-a descoperit ca diferite bucati de cod care lucrau cu utilizatori aveau multe in comun cand se folosea pachetul DBMS_SQL.din aceasta cauza s-a hotarat punerea acestor bucati de cod intr-un pachet. Acest pachet fost numit MG_USR, o prescurtare pentru "manager user".