kontrola dostepu Opcje

[evo]

Witam,


Chial bym rozpoczac dyskusje na temat w jaki sposob projektuje sie system z kontrola dostepu.

Osobiscie jestem na etapie mojego pierwszego projektu ,ktory wymaga wiecej niz dwoch stanow (admin, user), wymaga on grup o roznym zakresie dostepu do systemu

Zabardzo nie wiem jak sie do tego zabrac.

Sam moj system/jadro laduje odpowiednie wtyczki,ktore sa odpowiedzialane za dostep do danych. Do tej pory kontrolowalem dostep na polacie wyboru akcji, bo kazdy plugin choc do innei zawartosci obsluguje te same akcje (add,remove,edit,show) wiec po wyborze wtyczki lecz przed wyborem akcji sprawdzalem czy uzytkownik ma prawo do tego, lecz teraz potrzebje wiekszej wolnosci tzn. niektorzy moga miec dostep do czegos do czego inni nie i na odwrot.

I zastanawiam sie czy nie przeniesc kontroli dostepu do samych akcji dostepu do danych, czy moze lepiej wymagac od wtyczki by opisala kto ma do jakich akcji dostep a sama kontrole zostawic w jadrze.




Wszelkie uwagi i pomysly sa mile widziane jak i wszelkiego rodzaju materialy, ktore wcale nie musza byc oparte na przykladach php, lecz duzym plusem by bylo gdyby opisywaly schemat kontroli dostepu w aplikacjach web. Jezyk Niemiecki,Angielski lub Polski.

Z gory dziekuje i pozdrawiam
evo

[Ludvik]

Wygląda to tak:

Mamy akcję, która manipuluje danymi. Chcemy mieć kilka różnych zestawów danych, które będą istniały niezależnie od siebie. Musimy jakoś identyfikować te zestawy - intuicyjnie będziemy je oznaczać liczbami naturalnymi. W momencie wywołania akcji musi być znany identyfikator zestawu. Przed wywołaniem akcji musimy do naszego kontrolera (za kontroler przyjmiemy system autoryzacji) przekazać:
- Nazwę akcji
- Parametry z jakimi ją wywołujemy
- Specyfikację dostępu (czyli grupy, role i ich parametry)

Następnie musimy mieć dostęp do obiektu użytkownika, który będzie zawierał informację o rolach i grupach oraz ich parametrach. Teraz możemy wszystko porównać.

Przykład:
Użytkownik posiada rolę doAction, do której musimy przekazać parametry - domyślnie nie ma żadnego. Podajemy numer zestawu - powiedzmy, że 1. Akcję więc opisujemy następująco: doAction(1). Co z grupami? Podając parametry dla grupy możemy je jednakowo przekazać wszystkim rolom (jeżeli nasza hierarchia wygląda tak jak u Halfika).

Akcja wymaga roli doAction. Możemy wydzielić trzy metody postępowania z parametrami:
1. Parametry są opcjonalne (to raczej tylko dla wstecznej zgodności...).
2. Parametry są wymagane - jeżeli nie ma żadnego, to rola nie ma sensu.
3. Nie ma parametrów.

Teraz przechodzimy do meritum sprawy (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Kontroler otrzymuje żądanie autoryzacji tego użytkownika dla tej akcji oraz podaje parametry z jakimi ma zostać wywołana akcja. Używamy zestawu pierwszego, więc interesującym nas parametrem będzie "id", którego wartość będzie równa 1. Konfiguracja akcji wymaga posiadania roli doAction oraz parametru. Jak zatem powiedzieć kontrolerowi o co nam chodzi? Musimy w jakiś sposób przekazać mu informację o tym, że musimy znaleźć na liście parametrów roli konkretny parametr akcji. Zapiszmy to tak:

Kod

Required: doAction($id)

Teraz cały proces autoryzacji będzie wyglądał następująco:
1. Szukamy akcji doAction.
2. Pobieramy parametr id z żądania (posiada wartość 1).
3. Porównujemy listę parametrów roli (która w tym przypadku jest jednoelementowa, a jej jedyny element ma wartość 1).

Jeżeli znajdziemy parametr na liście, to zezwalamy na wywołanie akcji. W przeciwnym wypadku zmieniamy ścieżkę wykonania programu.

Tak to mniej więcej wygląda.

Uwagi:
- Kolejność parametrów jest ignorowana, szukamy tylko wspólnych elementów.
- Parametr może być dowolną wartością skalarną.
- Jeżeli chcemy wprowadzić dostęp do wszystkich zestawów, możemy przypisać roli użytkownika jeden parametr "*".
- Podział odpowiedzialności akcji musi być odpowiedni, aby nie pomieszać parametrów. Lepiej pomyśleć chwilę nad konstrukcją akcji niż mieszać przy konstrukcji parametrów.
- Jeżeli wywołamy akcję z fikcyjnym zestawem np. 13, wtedy użytkownik nie otrzyma uprawnień i może zostać wyrzucony błąd autoryzacji. To jest nieprawda, gdyż użytkownik nie ma prawa mieć dostępu do czegoś, co nie istnieje. Wypada sprawdzić wcześniej czy faktycznie ten zestaw istnieje.

Zapis parametrów w bazie jest luźny - lekko zmieniamy formę, w której zapisywaliśmy role/grupy. Musimy tylko umieć skojarzyć identyfikator zestawu z parametrami ról.

Update:
Tak by wyglądał przykłądowy wpis do bazy:

Kod

user = login
roles = doAction(1,5,9);doOtherAction(3);doAnything(*)
groups = someGroup(1,3,7)

Jeżeli grupa by wyglądała tak:

Kod

name = someGroup
roles = roleOne;roleTwo

To użytkownik by posiadał ostatecznie role doAction(1,5,9), doOtherAction(3), doAnything(*), roleOne(1,3,7), roleTwo(1,3,7). To jest tylko przykładowy zapis.

Mam nadzieję, że jest w miarę jasno i nie zapomniałem o niczym.

Ten post edytował Ludvik 8.12.2005, 22:03:53