Wzorce/sugestie dotyczące projektowania do obsługi uprawnień

Question

Mamy dość skomplikowany system obsługi uprawnień w naszej aplikacji (ASP.NET web). Użytkownicy mogą mieć określone uprawnienia dla różnych rodzajów obiektów, niektóre uprawnienia są nawet spakowane w grupy/role, które są przypisane do użytkowników. W sumie kończy się to dość skomplikowanym bałaganem, w którym do określenia, czy użytkownik może zrobić/zobaczyć coś, trzeba ocenić wiele różnych źródeł uprawnień, a odbywa się to w pewien sposób na żądanie i na podstawie konkretnych sytuacji.

Moje pytanie jest (z wysokiego poziomu widzenia), czy istnieją pewne sugestie/typowe wzorce projektowe, aby poradzić sobie z koncepcją uprawnień w ogóle i prawdopodobnie także, jakie jest twoje doświadczenie z obchodzeniem się z nimi w twojej architekturze.

Answer 1

Użytkownicy i Grupy z możliwością przetestowania bool UserHasPermission(SOME_PERMISSION) za zgodą atomowym związanym z Grupy jest standardowe podejście do autoryzacji, jednak coś się zmienia roszczeń opartych na:

http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

http://msdn.microsoft.com/en-us/magazine/cc163366.aspx

http://www.infoq.com/news/2009/10/Guide-Claim-Based-Identity

Jednak nie jest idealny we wszystkich sytuacjach.

W przypadku starego modelu stwierdzam, że wydajność można uzyskać za pomocą zapamiętywania podczas sprawdzania uprawnień. W ten sposób nie będę przechodzić do bazy danych n razy na sesję, aby sprawdzić kontrolę dostępu. Memoization skutecznie przechowuje w pamięci podręcznej wynik połączenia z tymi samymi parametrami, więc wszystkie połączenia danego użytkownika do sprawdzenia uprawnień XYZ zwrócą ten sam wynik. Oczywiście, upewnij się, że zachowałeś zapamiętane uprawnienia dla użytkownika w Sesji, więc jest to dla każdego użytkownika. Jeśli załadujesz uprawnienia przy logowaniu, nie musisz ich buforować, ale w dużych systemach z wieloma uprawnieniami czasami najlepiej jest je zdobywać tylko wtedy, gdy są potrzebne.

http://www.infoq.com/news/2007/01/CSharp-memory

Answer 2

I nie mieć do czynienia z tym z punktu widzenia rozwoju aplikacji, ale często w kontaktach z uprawnieniami jest to dobra praktyka, aby ustawić uprawnienia dla obiektów za pomocą ról, zamiast dając użytkownikom uprawnienia bezpośrednio do obiektu. Jeśli użytkownik potrzebuje dostępu do określonego zestawu obiektów, nie dajesz im bezpośredniego dostępu, zamiast tego dajesz im rolę, która z kolei ma wymagany dostęp. To w pewnym sensie "wykorzystuje" pracę, która została użyta do stworzenia roli.

Radzenie sobie z tym w kodzie może jednak skomplikować się, ponieważ trzeba powtórzyć każdą z ról użytkownika i określić, czy rola daje użytkownikowi uprawnienia do obiektu. Nie znam żadnych konkretnych sugestii, jak sobie z tym poradzić, poza tym, że próbuję zinterpretować ten rodzaj kodu we własne ramy.

Answer 3

Widziałem kilka skomplikowanych schematów uprawnień. Zawsze było to uzasadnione, ale niestety, w pewnym momencie, wszystkie stały się zbyt skomplikowane, aby poradzić sobie z nimi i zostały zredukowane do czegoś prostszego.

Moja osobista konkluzja brzmi: kij do Rola kontroli dostępu baza (RBAC) jest to jedyny rozsądny, który wszyscy rozumieją. Jest to w pewien sposób ograniczone, ale wystarczające w większości przypadków.

Stosuj również domyślnie zasady odmowy, to znaczy, że przyznajesz tylko prawa.Ponownie, widziałem system z przeciwieństwem (domyślnie zezwalaj) lub nawet konfigurowalną domyślną polityką (!) I nie uważam tego za rozsądną.