Oto mały diagram UML mający na celu opisać moją koncepcję klas Autoryzacji i Uwierzytelniania oraz zależności miedzy nimi. Co o tym sądzicie?

[PHP] pobierz, plaintext 
<?php
 
   interface IAuthorization
   {
      public function IsAllowed($sAction);
      public function SetDataSource(IAuthorizationDataSource $oDataSource);
   }
 
   interface IAuthorizationDataSource
   {
      public function GetAuthorizationData();
   }
 
   interface IAuthentication 
   {
      public function Login($sUsername, $sPassword);
      public function Logout();
   }
 
?>
[PHP] pobierz, plaintext 

Umożliwiło by to dowolny sposób autoryzacji użytkownika. Role, phpGACL itp.
Można by także zaimplementować intefejs IAuthorizationDataSource pod którąś z klas warstwy modelu. Czekam na krytyke :]

ps. ciekawe czy ktoś doceni moje umiejętności robienia diagramów UML w MS Paint :]

Ciężko powiedzieć, bo cała sztuka w tym, jak to się będzie integrowało z sesjami itd.

Dwie uwagi:
1) Nazwa klasy IAuthentication, IAuthorization jest IMHO zła, bo to nazwa czynności. Może lepiej IAuthorizer, IAuthenticator?
2) Ostatnio znalazłem jakiś dziwny framework, który jednakowoż miał kilka fajnych pomysłów odnośnie uwierzytelniania. M.in. oddzielne klasy do weryfikacji username+password i do wyciągania grup, do których user należy. Miało to sens, bo hasło sprawdzali np w htpasswd, etc/passwd i takich. A grupy z pliku ini.
3) Widzę, że próbujesz uniezależnić się od rodzaju autoryzacji. Co wtedy musi zwracać IAutorizationDataSource? Tablicę nazw akcji? Wtedy problem pojawi się znowu, tylko na niższym poziomie.
4) Ja się skłaniam (jak widać w punkcie 2) na rozwiązanie oparte o grupy. Bo znam tylko 2 rozwiązania: zagnieżdżone grupy lub RBAC. Ale role można przedstawić za pomocą grup . Oczywiście, co się później zrobi z listą grup użytkownika, to inna sprawa i tutaj będzie więcej możliwości...
5) Naprawdę MS Paint?! Jak tak, to kongratulejszynz, ale nie chce mi się wierzyć... A próbowałeś php2xmi? Bardzo wysoko na mojej liście todo.
6) Miały być dwie uwagi, ale jakoś tak wyszło

IAutorizationDataSource w moim zamierzeniu ma dostarczać takich danych jak np. wszystkie grupy do jakich należy user, wszystkie role jak ie posiada (mozna powiedziec ze to to samo, ale nei zawsze) itd...

Na podstawie tych danych IAutorization dokonuje sprawdzenia uprawnien. Dzieki temu mozna zarowno zmienic latwo miejsce przechowywania danych jak i kompletnie zmienic sposob autoryzacji (piszac wlasne IAutorization i odpowidni IAutorizationDataSource)

No to generalnie myślimy o tym samym Ale zaciekawiło mnie to z grupami: czy rzeczywiście ról użytkownika (i uprawnień, i co tam jeszcze jest w RBAC) nie można przedstawić za pomocą grup?

Można :] Ale ktoś może chcieć (pewnie i tak tylko ja, no ale nigdy nic nei wiadomo) zastosować inne mechanizmy autoryzacji, lub inne mechanizmy pobierania danych do sprawdzenia uprawnień. Tak więc ten "system" wydaje mi się maksymalnie elastyczny.

A co do sesji, get, post itd... Chyba wystarczy zwykłe pobieranie poprzez
Application::Instance()->GetRequest()

A w razie błędu rzucamy na lewo i prawo wyjątkami ;P

a co myślicie o takim sposobie autoryzacji:

[PHP] pobierz, plaintext 
<?php
interface Authorizator
{
	public function checkAccess( $iUser, $sObject, $sAction );
}
?>
[PHP] pobierz, plaintext 

Wtedy mamy dosy dużą elastycznośc i jest standardowy sposób autoryzacji:
"Czy $iUser może wykonac operację $sAction na obiekcie $sObject?"

pyt nr 2: Czy grupy wpleśc tylko w Autoryzacje? Czy też w ajkis sposób powiązac je z autentykacją?

A po co grupy przy uwierzytelnianu?

@matid: Przy uwierzytelnianiu faktycznie do niczego nie są potrzebne. Ale wynikiem uwierzytelniania może też być lista grup (jeżeli w ogóle używamy grup, of course).

@aleksander: Idea jest szczytna i w ogóle, tylko że za bardzo nie wiem, jak tym wszystkim zarządzać. Potrzebny jest identyfikator obiektu. Czy np. akcja w MVC jest obiektem? Czy identyfikator obiektu nie powinien być integerem?
Druga sprawa, że jeżeli wykorzystujemy grupy, to powinniśmy tej funkcji przekazywać również wszystkie grupy użytkownika.

a mnie się wydaje, że to Autoryzacja powinna zarzadza grupami więc sama w sobie wie, że dany user należy do danej/danych grup (ma swoje metody np:P)

Zauwarzyłem, że Twój tok myślenia jednak jest w phpGACL, ale nie widze żadnych płynącyc z tego kożyści:)

Można i tak, i tak... Ale IMHO znacznie lepiej jest to robić na etapie uwierzytelniania. Weźmy na przykład LDAP. Jeden fragment systemu połączy się z serwerem LDAP w celu sprawdzenia hasła, a drugi, zupełnie niezależny fragment zrobi to samo, tym razem w celu ustalenia grup, dbając o to, aby użyć tych samych parametrów połączenia. Nie da rady.

U mnie da się to zrobić ustawiając jako DataSource obiekt Uwierzytelniania, któy to po udanym logowaniu może trzymać w sobie dane o userze jak ID, username i grupy. Potem autoryzacja tylko pobiera te dane.

Odnosząc sie do całego tematu.

Ja sie uciekłem do pomysłu z podmianą kontrollera - można sobie wybrać który potrzebny - czy ten z uwierzytelnianem/autoryzacją czy bez

Co tematu Authorizer'a i innych - też mam coś takiego z tym, że ja sobie stworzyłem poprostu drivery do obu tych klas - ładny interfejsik i po bólu..