Jaki jest najlepszy mechanizm implementowania szczegółowych zabezpieczeń (np. Autoryzacja) w aplikacji ASP.NET MVC?

Załóżmy, że programiści pracujący z dużą szybkością mieli za zadanie zbudowanie aplikacji bankowej dostępnej dla wielu różnych osób. Każda osoba chciałaby uzyskać dostęp do swoich informacji o koncie, ale nie chciałaby, aby inni mieli do niej dostęp. Chciałbym poznać najlepszą praktykę ograniczania dostępu w aplikacji MVC, aby tylko użytkownik posiadający informacje (lub administrator) mógł uzyskać do niej dostęp.Jaki jest najlepszy mechanizm implementowania szczegółowych zabezpieczeń (np. Autoryzacja) w aplikacji ASP.NET MVC?

Atrybut Authorize pozwala nam ograniczyć rolę. Chociaż jest to punkt wyjścia, wydaje się, że każdy uwierzytelniony użytkownik może uzyskać dostęp do informacji innych użytkowników.

ActionFiltery wydają się oferować opcję bardziej szczegółowej kontroli i prawdopodobnie można by ją wykorzystać do wykonania zadania. Jednak nie jestem pewien, czy byłyby to zalecane podejście.

Wszelkie wskazówki i pomysły są mile widziane.

Źródło

2009-08-22 Anonymous

Co to jest "szybki programista"? –

Myślę, że masz rację, podejście ActionFilter jest rozsądne.

Stworzyłbym zestaw niestandardowych filtrów akcji odziedziczonych po AuthorizeAttribute.

Oprócz funkcjonalności atrybutu Autoryzuj, możesz w prosty sposób wdrożyć bardziej rygorystyczną politykę właściciela.

HTH,

Dan

Źródło

2009-08-22 06:34:12

Dziękuję Dan! Jakie są Twoje sugestie dotyczące wdrożenia "bardziej rygorystycznych zasad dla właścicieli"? Czy jest to coś podobnego do tego, co Mark opisał powyżej? –

Dokładnie Anthony, ostatni akapit w szczególności z odpowiedzi Marka. Będę czerpał twoje niestandardowe filtry z filtra Autoryzuj, ponieważ będziesz potrzebować autoryzowanego IPrincipala do sprawdzania z listą ACL. –

ActionFilter jest dobrym punktem wyjścia, ale w zależności od architektury, może warto rozważyć, czy obwód obronny jest wystarczająco dobre.

Jeśli zasadniczo tworzysz jednowarstwową aplikację ASP.NET MVC (i mogą to być uzasadnione powody), ActionFilter zapewni obronę, która jest wystarczająco dobra, a jednocześnie jest bardzo prosta do zastosowania. .

Z drugiej strony, jeśli aplikacja jest aplikacją wielowarstwową, właściwość Obrona w głębokości jest bardziej odpowiednia. W takim przypadku należy rozważyć zastosowanie logiki autoryzacji w Modelu domeny, a może nawet w warstwie dostępu do danych. Zapewni to, że jeśli kiedykolwiek stworzysz inną aplikację opartą na tym samym modelu domeny (np. Usługa sieciowa), nadal będzie obowiązywała logika autoryzacji.

Niezależnie od tego, co robisz, zdecydowanie zalecamy oparcie faktycznej realizacji autoryzacji na IPrincipal.

Bardziej konkretnie, to, o co tutaj pytasz, najlepiej jest modelować z autoryzacją opartą na ACL: Ustaw listę ACL dla każdego profilu użytkownika, który domyślnie zapewnia dostęp tylko samemu użytkownikowi i administratorowi. Jeśli/później będziesz musiał rozwinąć aplikację, aby umożliwić delegowany dostęp do profili innych użytkowników (nie wiem, czy jest to nawet zdalne w twoim konkretnym przypadku), możesz to zrobić, dodając nowy wpis do listy ACL.

W takim przypadku ocena dostępu obejmuje pobranie listy ACL dla żądanego zasobu i sprawdzenie, czy bieżący użytkownik (stopień) jest uwzględniony w tej liście ACL. Taka operacja najprawdopodobniej obejmuje operacje pozaprocesowe (sprawdzanie listy ACL w bazie danych), więc posiadanie jej jako ukrytej części aplikacji przez ukrywanie jej za działaniem ActionFilter brzmi, jakby mogło potencjalnie ukryć pewne problemy z wydajnością. W takim przypadku rozważałbym uczynienie modelu autoryzacji nieco bardziej oczywistym/widocznym.

Źródło

2009-08-22 08:37:13

Mark, to doskonała strategia! Dzięki! W większości moich poprzednich projektów napisaliśmy własne komponenty bezpieczeństwa do zarządzania licencjami, użytkownikami, grupami, rolami itp. I ominęliśmy architekturę członkostwa ASP.NET, aby uwzględnić kontrolę dostępu na niższych poziomach. Miałem NADZIEJĘ, że istnieje prostszy sposób na wdrażanie uprawnień w MVC niż samodzielne toczenie. Od mojego pierwszego postu napisałem go mimo wszystko, ale podjąłem podejście hybrydyczne. Użyłem członkostwa i dostawców roli ASP.NET dla podstawowego uprawnienia i roli MGMT, ale opracowałem własne zarządzanie grupami i uprawnieniami dla lepszej kontroli ziarnistości. –

Gdy użytkownik próbuje wykonać akcję (na kontrolerze), sprawdzam jego role, aby upewnić się, że ma on "podstawowy" dostęp. Jeśli nie, przekierowuję go. Jeśli ma podstawowy dostęp, wywołuje bardziej szczegółową funkcję sprawdzania jego rzeczywistych uprawnień w odniesieniu do określonego typu obiektu i/lub instancji, do której próbuje uzyskać dostęp. W tej chwili nie zaimplementowałem tego jako filtru akcji, ale po prostu wywołuję to w ramach każdej akcji. Niedługo to zrestrukturyzuję. –

Cieszę się, że możesz użyć odpowiedzi - możesz również sprawdzić tę odpowiedź, która jest nieco pokrewna: http://stackoverflow.com/questions/1335315/access-control-in-asp-net-mvc-depending-on -input-parameters-service-layer/1336404 # 1336404 –

Zgodnie z moim poglądem, jeśli masz aplikację jednowarstwową, autoryzacja jest najlepszą opcją, a także filtr działania jest znacznie lepszy i prostszy w użyciu. Ale jeśli twoja aplikacja jest wielowarstwowa, to musisz mieć listę kontroli dostępu do listy [ACL].

Źródło

2011-01-12 10:53:24 Asghar

Jeśli kiedykolwiek chcesz autoryzować na zewnątrz, możesz rzucić okiem na implementacje oparte na XACML.

Źródło

2011-11-15 19:43:18 kaptan

Jaki jest najlepszy mechanizm implementowania szczegółowych zabezpieczeń (np. Autoryzacja) w aplikacji ASP.NET MVC?

Odpowiedz

Powiązane problemy