Uprawnienia / odpowiedni model / wzór dla aplikacji .NET

Muszę wdrożyć elastyczne ORAZ proste (jeśli takie rzeczy istnieją), a jednocześnie w miarę możliwości korzystać z wbudowanych środków

Do tej pory mam wdrożone MembershipProvider i RoleProviders. To jest fajne, ale gdzie dalej?

Wydaje mi się, że muszę dodać termin „Przywilej” i zakodować te w aplikacji. Użytkownicy skonfigurują role, aby dodać uprawnienia do ról i przypisać role użytkownikom.

Czy to brzmi jak dobry model? Czy powinienem pomyśleć o dodaniu uprawnień na poziomie użytkownika oprócz dodawania ich do ról? Mogę, ale wyobrażam sobie problemy z konfiguracją (mylące) i podążaniem za wsparciem.

Jeśli tego nie zrobię, a niektórzy konkretni użytkownicy będą potrzebować mniejszych uprawnień - administrator będzie musiał utworzyć inną rolę itp.

Jakaś srebrna kula dla takiego systemu? I dlaczego Microsoft nie poszedł dalej niż tylko dostawcy członkostwa i roli?

Kolejny pomysł: pozostaw role jako właściciela „uprzywilejowanego” i zakoduj je na stałe. Następnie mogę zakodować te role w aplikacji za pomocą wszystkich dostępnych znaczników / atrybutów itp. - wszystkich Microsoft.

Dodaj nowy byt „Grupa” i utwórz relację w ten sposób

• Użytkownicy
• Grupy użytkowników
• Grupy
• RoleGroups
• Role

W ten sposób mogę zbierać role do grup i przypisywać te grupy Użytkownikom. Brzmi świetnie i pasuje do innych wzorców oprogramowania. Ale tak naprawdę nie mogę zaimplementować rzeczy w RoleProvider takich jak:

• AddUsersToRoles
• RemoveUsersFromRoles

A niektóre rzeczy nie mają już sensu, ponieważ zostaną zakodowane na stałe

• DeleteRole
• CreateRole

Jeśli autoryzacja oparta na rolach nie jest dla Ciebie wystarczająco szczegółowa, rozważ użycie autoryzacji opartej na oświadczeniach .

Oświadczenie opisuje zasób i działanie - coś w rodzaju wpisu na liście ACL, ale jest bardziej elastyczne, ponieważ „zasób” nie musi być obiektem fizycznym, może być czymkolwiek chcesz i może zawierać dowolne informacje chcesz.

W tym modelu oświadczenie jest równoważne z tym, co nazywasz „przywilejem”, i dzielisz roszczenia na zestawy oświadczeń, co w przybliżeniu odpowiada temu, co nazywasz „rolą”. Wszystkie te interfejsy API i inne są już w System.IdentityModelprzestrzeni nazw.

Oczywiście wspominasz MembershipProvideri RoleProviderjeśli próbujesz wcisnąć to wszystko w model członkostwa ASP.NET (jak sugerują te nazwy), po prostu o tym zapomnij. Jeśli chcesz używać interfejsów API dostawcy, musisz to zrobić po swojemu, a ich sposób działania nie jest bardziej szczegółowy niż koncepcja roli.

Zamiast tego w ASP.NET pojęcie „przywileju” jest faktycznie zakodowane na poziomie akcji lub operacji , gdzie deklarujesz, które role mogą wykonywać tę akcję. Jest to naprawdę o wiele łatwiejsze do rozwiązania w ASP.NET MVC, gdzie po prostu uderzasz [AuthorizeAttribute]kontrolery lub akcje kontrolerów; w „old-school” ASP.NET, zajmujesz się zdarzeniami, więc autoryzacja jest albo ad-hoc, albo na poziomie strony (lub obu).