Na wniosek nasty, który mam nadzieję rozwinie ten wątek

To może najpierw zaczniemy od małej sądy?

1. W jaki sposób identyfikujecie użytkoniwków swoich aplikacji?
2. Jeśli macie już istniejącąbazę użytkowników (np. intranet czy partnerska organizacja) to jak importujecie lub dajecie tym użytkownikom dostęp do Waszej aplikacji?
3. Gdzie i jakie dane o użytkownikach przechowujecie i w jaki sposób?
4. Jak udostępniacie swoich użytkoników partnerskim organizacjom?

Zapraszam do dyskusji - dzięki nospor!

@nasty

1. Prosty system sesji oparty albo o sesje php'owe [w celu przechowywania stałego SID'a lub 'sid' w ciasteczkach], dane o sesjach przechowuję w bazie danych i potem pobieram po id sesji
2. Prosty ACL, chociaż nawet prostym nie można tego nazwać, w tabeli users jest kolumna group_id i każdy może mieć przypisaną jedną grupę [można łatwo rozwinąć aby było kilka ale trzeba się pobawić potem z uprawnieniami kilku grup dla jednego użytkownika], w tabeli groups_acl sa kolumny acl_group, acl_can_view_cos, acl_can_cos_tam, pobieram te dane i robią kesz co by nie trzeba było bazy obciążać kolejnym bzdetem [$acl = array( grupa => array( ACL ) ) i potem w łatwy i zdaje mi się, że szybki sposób można pobrać info o uprawnieniach
3. Baza danych, session_id, session_start, session_last, session_location, session_user -> pierwsza i ostatnia kolumna najważniejsza [po nazwach można się domyślić do czego służą ;p]
4. ---

ja to robię w taki sposób [mniej więcej], jak na razie nie napotkałem żadnych problemów ale na pewno są lepsze rozwiązania.

A może lepiej byłoby trzymać sesję client-side? Wiem że wydaje się to głupie, ale gdyby użyć algorytmu który by szyfrował sesję, taką sesję trzymał po stronie usera,a po połączeniu deszyfrował - miało by to sens?

Tym bardziej, że kusi praktycznie usunięcie problemu ,,sticky sessions" , jak mamy np. parę równoległych maszyn.

Pozdrawiam

A Zastanawialiście się kiedyś o tym, żeby wyeliminować kwestię autentykacji użytkowników w Waszych aplikacjach i wydelegowania tego procesu innym instytucjom? Mowa to o Claims-Based Identity.

Identyfikacja użytkownika za pomocą driver-a LDAP. Niestety nie mam środowiska testowego, żeby przetestować na IIS 7.5 możliwość zrobienia logowania poprzez KERBEROS-a.

Co lepsze:
tabela sessions
sid, session_timeout, session_data (zserializowana tablica)

następnie klasa Sessions pobiera sesję z bazy po sid, sprawdza session_timeout, następnie z session_data wyciąga user_id do którego należy sesja, pobiera użytkownika i zapisuje wiersz w tablicy ew. tworzy obiekt User

lub takie coś
sid, session_timeout, session_user, session_data
to samo co wyżej, z tym, że sesja pobiera po sid i dołącza użytkownika z bazy w jednym zapytaniu (LEFT JOIN)?

1. System na sesjach, ustalony czas trwania sesji i wylogowanie po tym czasie lub przedłużenie sesji.
2. Rozbudowany ACL gdzie user ma prawa podstawowe zależne od roli (admin, moderator itp) następnie od grupy(może być kilka) i ostatecznie od uprawnień dla danego usera(mają one pierwszeństwo ponad prawami roli i grupy)
3. Tabela w bazie zawiera osobno informacje o acl, osobno o użytkowniku i osobno o jego profilu, w momencie zalogowania dane usera są łączone z jego profilem.
4. ---

Nie będę tutaj powielał najczęstszych odpowiedzi, którymi zapewne mogą być sesja + ciastko + user w bazie, więc opiszę jak to robię przy okazji połączeń z serwisami poprzez API.

1. OAuth2 w których do tokena dostępowego zabindowany jest User.
2. Podpięcie aktualnej bazy użytkowników to kwestia dodania kolejnego klienta uwierzytelniającego dane z zewnętrznego. Jeśli istnieje zewnętrzna baza użytkowników z możliwością autoryzacji - istnieje sam system autoryzacji dostępu. Najprostszym zatem jest - autoryzacja użytkownika w swoim "naturalnym" środowisku, a następnie przyznanie mu dostępu do naszego serwisu.
3. Baza danych, niepotrzebne są jakiekolwiek pola z saltem, hashem hasła (bo takowe nie istnieje) etc.
4. Nawet pomiędzy większymi elementami wewnątrz jednego projektu - 3 stopniowa autoryzacja, którą zapewnia OAuth.

Ogromnym plusem jest tutaj łatwość wpięcia autoryzacji typu stateless (zero ciastek) do już istniejącej bazy użytkowników, i w drugą stronę - dopięcia standardowego logowania do istniejącego systemu.

Jaki jest aktualny trend w sesjach? Jakaś klasa opakowywująca sesje PHPowe w settery i gettery + jakieś dodatki, czy może handler zapisywania sesji do bazy a może kompletny, w 100% własny sposób na sesje, gdzie w ciasteczku sami zapisujecie SID i potem pobieracie sesję z bazy, jak rozwiązują to frameworki, jak jest najlepiej to rozwiązać?

Z tego co wiem, to nowe Symfony używa sesji PHPowej, ale opakowanej ładnie w klasę. Próbowałem napisać własny mechanizm sesji, ale jest to "droga przez mękę" i nikomu tego nie polecam. Nie warto wymyślać koła na nowo, skoro jest ono już wymyślone (de facto ja zacząłem tak robić, ale poszedłem po rozum do głowy). Chodzi mi o natywną sesję PHP. Oczywiście, trzeba ją troszkę dostosować, poprawić, zabezpieczyć, ale jak już się to zrobi to nie ma nic lepszego.

W aplikacji firmowej używamy sesji PHP, ale opakowanej ładnie w klasę, a dodatkowo dane trzymamy w bazie danych. Są to jednak zawsze dwa zapytania więcej do DB, ale można dzięki temu zapisywać i pobierać statystyki na temat aktywnych użytkowników itp. Ważne jest by zabezpieczyć domyślną sesję PHP przed atakami, a reszta to już inwencja własna

W swoich aplikacjach korporacyjnych robię autoryzację po Kerberosie w domenie ActiveDirectory (wcześniej apache2 i IIS, teraz nginx). Sama aplikacja PHPowa, napisana w SF2 - gdzie napisałem własną paczkę do obsługi autoryzacji via Kerberos, zarządza tylko poszczególnymi uprawnieniami dla nazw użytkowników. Wynika to z tego, że nie mamy wjazdu na LDAPowe grupy uprawnień.
Rozwiązanie bardzo wygodne dla developera i co najważniejsze - dla użytkownika.

Czytam ten topic, i zauważyłem ze niektórym z was brakuje fundamentalnej wiedzy na temat uwierzytelniania i autoryzacji.

Używacie ciągle slow autentykacja i autoryzacja w tym samym kontekście. Nie ma czegoś takiego jak autentykacja, jest uwierzytelnianie czyli w naszym świecie, proces zidentyfikowania użytkownika, nie ważne czy jego konto jest nie aktywne, zbanowane czy bóg wie co jeszcze, uwierzytelniłeś użytkownika ponieważ byleś wstanie na podstawie jego requestu dojść do obiektu konta lub jakiejkolwiek innej reprezentacji usera.

Autoryzacja zarazem to proces gdzie przydzielasz użytkownikowi jakieś możliwości dostępu, czyli jeśli dochodzisz do etapu sprawdzenia czy to konto jest zbanowane lub nie aktywne, lub czy ma dostęp do tego obiektu, to jest własnie autoryzacja.

A co do samego procesu używanego prze zemnie, zależy to od kontekstu, jeśli jest to API, to OAuth lub BasicAuth, w innych przypadkach, po prostu ciasteczka.