Kontrola dostępu oparta na rolach (RBAC) a kontrola dostępu oparta na oświadczeniach (CBAC) w ASP.NET MVC

Jakie są główne zalety korzystania z CBAC w porównaniu z RBAC ? Kiedy lepiej jest używać CBAC, a kiedy lepiej używać RBAC?

Próbuję zrozumieć ogólne koncepcje modelu CBAC, ale ogólna idea wciąż nie jest dla mnie jasna.

Spróbuję pokazać, jak możesz skorzystać z kontroli dostępu opartej na oświadczeniach w kontekście ASP.NET MVC.

Jeśli używasz uwierzytelniania opartego na rolach, jeśli masz akcję tworzenia klienta i chcesz, aby osoby pełniące rolę `` Sprzedaż '' mogły to zrobić, pisz kod w następujący sposób:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Później zdałeś sobie sprawę, że czasami osoby z roli „Marketing” powinny być w stanie stworzyć Klienta. Następnie zaktualizuj swoją metodę Action w ten sposób

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Teraz zdałeś sobie sprawę, że niektórzy marketingowcy nie mogą być w stanie stworzyć Klienta, ale nie jest możliwe przypisanie innej roli tym osobom, które zajmują się marketingiem. Więc jesteś zmuszony pozwolić wszystkim marketingowcom na tworzenie Klientów.

zauważyłeś inny problem, za każdym razem, gdy zdecydujesz, że pracownicy marketingu powinni mieć możliwość tworzenia klientów, musisz zaktualizować wszystkie metody akcji MVC. Atrybut Autoryzuj, skompiluj aplikację, przetestuj ją i uruchom. Kilka dni później zdecydowałeś, że nie marketing, ale inna rola powinna być dopuszczona do wykonania zadania, więc przeszukujesz swoją bazę kodów i usuwasz wszystkie `` Marketing '' z atrybutu Authorize i dodajesz nową nazwę roli w atrybucie Authorize ... To nie jest zdrowe rozwiązanie. W tym momencie zdasz sobie sprawę z potrzeby kontroli dostępu opartej na uprawnieniach.

Kontrola dostępu oparta na uprawnieniach to sposób przypisywania różnych uprawnień różnym użytkownikom i sprawdzania, czy użytkownik ma uprawnienia do wykonywania akcji z kodu w czasie wykonywania. Po przypisaniu różnych uprawnień różnym użytkownikom zdajesz sobie sprawę, że musisz zezwolić niektórym użytkownikom na wykonanie kodu, jeśli użytkownik ma jakąś właściwość, taką jak „Użytkownik Facebooka”, „Długotrwały użytkownik” itp. Podam przykład. Załóżmy, że chcesz zezwolić na dostęp do określonej strony, jeśli użytkownik jest zalogowany za pomocą Facebooka. Czy mógłbyś teraz utworzyć pozwolenie „Facebook” dla tego użytkownika? Nie, „Facebook” nie brzmi jak pozwolenie. Czy to ? Raczej brzmi to jak roszczenie. Jednocześnie uprawnienia mogą brzmieć jak Claim !! Dlatego lepiej sprawdzić roszczenia i zezwolić na dostęp.

Wróćmy teraz do konkretnego przykładu kontroli dostępu opartej na oświadczeniach.

Możesz zdefiniować taki zestaw roszczeń:

„CanCreateCustomer”, „CanDeleteCustomer”, „CanEditCustomer” .. itd.

Teraz możesz udekorować swoją metodę działania w następujący sposób:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(Uwaga: [ClaimAuthorize (Permission = "CanCreateCustomer")] może nie być wbudowane w bibliotekę klas MVC, pokazuję tylko jako przykład, możesz użyć jakiejś biblioteki klas, która ma taką definicję klasy Attribute)

Teraz możesz zobaczyć, że metoda akcji CreateCustomer zawsze będzie wymagała pozwolenia „CanCreateCustomer” i nigdy się nie zmieni lub prawie się nie zmieni. Dlatego w bazie danych tworzysz tabelę uprawnień (oświadczeń) i relacji użytkownik-uprawnienia. W panelu administracyjnym możesz ustawić uprawnienia (roszczenia) dla każdego użytkownika, który może co robić. Możesz przypisać uprawnienie (roszczenie) „CanCreateCustomer” do dowolnej osoby, a tylko uprawniony użytkownik będzie mógł utworzyć klienta, a uprawniony użytkownik będzie mógł tworzyć tylko klienta i nic więcej (chyba że przypiszesz inne uprawnienia temu samemu użytkownikowi).

Ten model bezpieczeństwa oferuje praktykę czystego kodu. Co więcej, pisząc swoją metodę akcji, nie musisz myśleć o tym, kto może jej używać, raczej zawsze możesz być pewien, że ktokolwiek używa tej metody, będzie miał odpowiednie pozwolenie (roszczenie) udzielone przez administratora. Następnie Administrator może zdecydować, kto będzie mógł co robić. Nie ty jako programista. W ten sposób logika biznesowa jest oddzielona od logiki bezpieczeństwa.

Za każdym razem, gdy ktoś się zaloguje, Twoja aplikacja sprawdzi, jakie uprawnienia są dostępne dla tego użytkownika i ten zestaw uprawnień (roszczeń) będzie dostępny jako dodatkowe właściwości aktualnie zalogowanego użytkownika (zwykle zestaw oświadczeń jest przechowywany jako plik cookie dla zalogowanego użytkownika), więc nie musisz cały czas sprawdzać zestawu uprawnień z bazy danych. Najważniejsze jest to, że uzyskasz większą kontrolę nad logiką bezpieczeństwa w swojej aplikacji, jeśli zastosujesz dostęp oparty na oświadczeniach, a nie na rolach. W rzeczywistości rolę można również uznać za roszczenie.

Jeśli twoja aplikacja jest bardzo małą aplikacją, w której byłyby tylko 2 role: klient i administrator i nie ma szans, że klient będzie mógł zrobić cokolwiek innego niż to, co ma zrobić w twojej aplikacji, to być może na podstawie ról kontrola dostępu będzie służyć temu celowi, ale wraz z rozwojem aplikacji w pewnym momencie zaczniesz odczuwać potrzebę kontroli dostępu opartej na roszczeniach.

Wielokrotnie wdrażałem modele bezpieczeństwa i musiałem też omijać te koncepcje. Robiłem to wiele razy, oto moje rozumienie tych pojęć.

Jakie są role

Rola = Unia użytkowników i uprawnień.

Z jednej strony rola to zbiór uprawnień. Lubię nazywać to profilem uprawnień. Definiując rolę, po prostu dodajesz kilka uprawnień do tej roli, więc w tym sensie rola jest profilem uprawnień.

Z drugiej strony Rola to także zbiór użytkowników. Jeśli dodam Boba i Alicję do roli „Menedżerowie”, wówczas „Menedżerowie” będą teraz zawierać zbiór dwóch Użytkowników, coś w rodzaju grupy.

Prawda jest taka, że ​​rola to ZARÓWNO zbiór użytkowników, jak i zbiór uprawnień. Wizualnie można to zobaczyć jako diagram Venna.

Co to jest grupa

Grupa = kolekcja użytkowników

„Grupa” to ściśle zbiór użytkowników. Różnica między grupą a rolą polega na tym, że rola ma również kolekcję uprawnień, ale grupa ma tylko kolekcję użytkowników.

Co to jest pozwolenie

Pozwolenie = co podmiot może zrobić

Co to jest zestaw uprawnień

Zestaw uprawnień = zbiór uprawnień

W solidnym systemie RBAC uprawnienia można również grupować jak Użytkownicy. Podczas gdy grupy są tylko zbiorem użytkowników, zestaw uprawnień to tylko zbiór uprawnień. Pozwala to administratorowi na jednoczesne dodawanie całych kolekcji uprawnień do ról.

Jak łączą się użytkownicy, grupy, role i uprawnienia

W solidnym systemie RBAC Użytkownicy mogą być dodawani do roli indywidualnie, aby utworzyć kolekcję użytkowników w roli lub grupy można dodawać do roli, aby jednocześnie dodawać kolekcję użytkowników do roli. Tak czy inaczej, rola uzyskuje kolekcję użytkowników z indywidualnego dodania lub dodania grup do roli lub przez dodanie kombinacji użytkowników i grup do roli. Uprawnienia można traktować w ten sam sposób.

Uprawnienia można dodawać do ról indywidualnie, aby utworzyć kolekcję uprawnień w ramach roli lub zestawy uprawnień można dodać do roli. Wreszcie, do roli można dodać kombinację uprawnień i zestawów uprawnień. Tak czy inaczej, rola otrzymuje swój zbiór uprawnień z indywidualnego dodania lub przez dodanie zestawów uprawnień do roli.

Celem ról jest poślubienie użytkowników z uprawnieniami. Dlatego rolą jest UNIA użytkowników i uprawnień.

Co to są roszczenia

Claim = Czym jest temat

Roszczenia NIE są uprawnieniami. Jak wskazano w poprzednich odpowiedziach, twierdzenie jest tym, co podmiot „jest”, a nie tym, co podmiot „może zrobić”.

Oświadczenia nie zastępują ról ani uprawnień, są to dodatkowe informacje, których można użyć do podjęcia decyzji o autoryzacji.

Kiedy korzystać z oświadczeń

Zauważyłem, że roszczenia są przydatne, gdy trzeba podjąć decyzję dotyczącą autoryzacji, gdy nie można dodać użytkownika do roli lub decyzja nie jest oparta na powiązaniu użytkownika z uprawnieniem. Powoduje to przykład użytkownika Facebooka. Użytkownikiem Facebooka nie może być ktoś, kto został dodany do „Roli”… jest tylko jakimś Gościem uwierzytelnionym przez Facebooka. Chociaż nie pasuje do RBAC, jest to informacja, na podstawie której należy podjąć decyzję o autoryzacji.

@CodingSoft użył metafory klubu nocnego w poprzedniej odpowiedzi, którą chciałbym rozszerzyć. W tej odpowiedzi prawo jazdy zostało użyte jako przykład zawierający zestaw roszczeń, w których data urodzenia reprezentuje jedno z roszczeń, a wartość roszczenia DateOfBirth służy do sprawdzenia zgodności z regułą autoryzacji. Rząd, który wydał prawo jazdy, jest organem, który nadaje roszczeniu autentyczność. Dlatego w scenariuszu z klubem nocnym bramkarz przy drzwiach patrzy na prawo jazdy danej osoby, upewnia się, że zostało wydane przez zaufany organ, sprawdzając, czy jest to fałszywy dowód tożsamości (tj. Musi być ważnym dokumentem wydanym przez rząd), następnie sprawdza datę urodzenia (jedno z wielu stwierdzeń na prawie jazdy), a następnie wykorzystuje tę wartość, aby określić, czy dana osoba jest wystarczająco dorosła, aby wejść do klubu. W takim razie,

Teraz, mając na uwadze tę podstawę, chciałbym to teraz rozszerzyć. Załóżmy, że budynek, w którym znajduje się klub nocny, zawiera biura, pokoje, kuchnię, inne piętra, windy, piwnicę itp., Do których mogą wejść tylko pracownicy klubu. Ponadto niektórzy pracownicy mogą mieć dostęp do określonych miejsc, których inni pracownicy nie mogą. Na przykład kierownik może mieć dostęp do wyższego piętra w biurze, do którego inni pracownicy nie mają dostępu. W tym przypadku istnieją dwie role. Menedżer i pracownik.

Podczas gdy dostęp gości do publicznego obszaru klubu nocnego jest dozwolony w pojedynczym roszczeniu, jak wyjaśniono powyżej, pracownicy potrzebują dostępu według roli do innych niepublicznych pomieszczeń o ograniczonym dostępie. Dla nich prawo jazdy nie wystarczy. Potrzebują plakietki pracownika, którą skanują, aby wejść do drzwi. Gdzieś istnieje system RBAC, który przyznaje odznaki w roli menedżera dostęp do najwyższego piętra, a odznaki w roli pracownika - dostęp do innych pomieszczeń.

Jeśli z jakiegoś powodu pewne pokoje muszą zostać dodane / usunięte przez rolę, można to zrobić za pomocą RBAC, ale nie jest to odpowiednie dla roszczenia.

Uprawnienia w oprogramowaniu

Kodowanie ról w aplikacji to zły pomysł. To sztywno koduje cel roli w aplikacji. To, co powinna mieć aplikacja, to tylko uprawnienia, które działają jak flagi funkcji. Tam, gdzie flagi funkcji są udostępniane przez konfigurację, uprawnienia są udostępniane przez kontekst zabezpieczeń użytkownika, który jest uzyskiwany z kolekcji uprawnień DISTINCT zebranych ze wszystkich ról, w których został umieszczony użytkownik. Nazywam to „uprawnieniami efektywnymi”. Aplikacja powinna przedstawiać tylko plik menumożliwych uprawnień do funkcji / działań. System RBAC powinien wykonać zadanie poślubienia tych uprawnień z użytkownikami poprzez role. W ten sposób nie ma sztywnego kodowania ról, a uprawnienie zmienia się tylko wtedy, gdy jest usuwane lub dodawane jest nowe. Po dodaniu uprawnienia do oprogramowania nie należy go nigdy zmieniać. Powinien być usuwany tylko wtedy, gdy jest to konieczne (tj. Gdy funkcja jest wycofywana w nowej wersji) i można dodawać tylko nowe.

Ostatnia uwaga.

Grant vs Deny

Solidny system RBAC, a nawet system CBAC powinien rozróżniać granty i odmowy.

Dodanie pozwolenia do roli powinno wiązać się z GRANTEM lub DENY. Gdy uprawnienia są zaznaczone, wszystkie UDZIELONE uprawnienia powinny zostać dodane do listy Aktywnych uprawnień Użytkownicy. Po wykonaniu tego wszystkiego lista ODRZUCONYCH uprawnień powinna spowodować, że system usunie te uprawnienia z listy aktywnych uprawnień.

Umożliwia to administratorom „modyfikowanie” ostatecznych uprawnień podmiotu. Najlepiej, jeśli uprawnienia można również dodawać bezpośrednio do użytkowników. W ten sposób możesz dodać użytkownika do roli menedżera i uzyskać dostęp do wszystkiego, ale być może chcesz ODMOWAĆ dostępu do toalety dla kobiet, ponieważ użytkownik jest mężczyzną. Dodajesz więc mężczyznę do roli menedżera i dodajesz uprawnienie do obiektu użytkownika za pomocą opcji ODMOWA, aby odebrać dostęp tylko tej Pani do pokoju.

Właściwie byłby to dobry kandydat do roszczenia. Jeśli Użytkownik ma roszczenie „płeć = mężczyzna”, to pełnienie roli menedżera zapewnia dostęp do wszystkich pokoi, ale toaleta dla kobiet wymaga również roszczenia „płeć = kobieta”, a toaleta męska wymaga roszczenia „płeć = mężczyzna”. W ten sposób nie trzeba byłoby konfigurować uprawnienia ODMOWA dla użytkowników płci męskiej, ponieważ egzekwowanie roszczeń zajmuje się tym wszystkim z jedną regułą autoryzacji. Jednak można to zrobić tak czy inaczej.

Chodzi o to, że odmowa uprawnień ułatwia zarządzanie rolami, ponieważ można zaimplementować wyjątki.

Poniżej znajduje się schemat, który zrobiłem dawno temu, który przedstawia model RBAC. Nie mam grafiki dla roszczeń, ale możesz sobie wyobrazić, że są to tylko atrybuty przypisane do użytkowników, gdziekolwiek się znajdują. Diagram nie pokazuje również grup (w pewnym momencie muszę go zaktualizować).

Mam nadzieję, że to pomoże.

To jest schemat RBAC opisany powyżej

Aktualizacja z 7 kwietnia 2019 r. Na podstawie opinii od @Brent (dziękuję) ... usunięto niepotrzebne odniesienia do poprzednich odpowiedzi i wyjaśniono pierwotną podstawę metafory „klubu nocnego” dostarczonej przez @CodingSoft, aby ta odpowiedź była zrozumiała bez konieczności przeczytać inne odpowiedzi.

Nie do końca zgadzam się z odpowiedzią Emrana

[Authorize(Roles="Sale")]

Jest naiwny

Pytanie brzmi jak

  [Authorize(Roles="CustomerCreator")]

jest inny od

 [ClaimAuthorize(Permission="CanCreateCustomer")]

Jeśli oba są równie dobre, dlaczego potrzebujemy roszczenia?

Myślę, ponieważ

Koncepcja oświadczeń jest bardziej ogólna w porównaniu z rolą

W kontekście powyższego przykładu możemy powiedzieć, że „CustomerCreator” to żądanie typu „role” zapewniane przez „Asp.NETroleProvider”

Dodatkowe przykłady roszczeń.

1. „AAA” to roszczenie typu „MYExamSite.Score” dostarczone przez „MYExamSite.com”

2. „Złoto” to roszczenie typu „MYGYM.Membershiptype” dostarczone przez „MYGYMApp”

Zaakceptowana odpowiedź wydaje się pozycjonować role jako tępy przedmiot, a roszczenia jako elastyczne narzędzie, ale poza tym sprawia, że ​​wydają się one prawie identyczne. Niestety, takie umiejscowienie szkodzi pojęciu roszczeń i może zasadniczo odzwierciedlać niewielkie niezrozumienie ich celu.

Role istnieją i mają sens tylko w niejawnym zakresie. Ogólnie jest to aplikacja lub zakres organizacyjny (np. Rola = Administrator). Z drugiej strony, roszczenia mogą być „zgłaszane” przez każdego. Na przykład uwierzytelnianie Google może generować oświadczenia zawierające „e-mail” użytkownika, dołączając w ten sposób ten e-mail do tożsamości. Google zgłasza roszczenie, aplikacja decyduje, czy je zrozumieć i zaakceptować. Sama aplikacja może następnie dołączyć oświadczenie o nazwie „authenticationmethod” (tak jak robi to ASP.NET MVC Core Identity) z wartością „Google”. Każde roszczenie obejmuje zakres, dzięki czemu można określić, czy roszczenie ma znaczenie zewnętrzne, lokalne, czy oba (lub w razie potrzeby bardziej szczegółowe).

Najważniejsze jest to, że wszystkie oświadczenia są jawnie dołączone do tożsamości i obejmują jawny zakres. Oświadczenia te mogą oczywiście służyć do autoryzacji - a ASP.NET MVC zapewnia obsługę tego za pośrednictwem atrybutu Authorize, ale nie jest to jedyny lub nawet główny cel Claims. Z pewnością nie odróżnia go od ról, których można używać w dokładnie taki sam sposób do autoryzacji o zasięgu lokalnym.

Można więc zdecydować się na użycie ról lub roszczeń, lub obu w celu autoryzacji, i prawdopodobnie nie znajdzie żadnej nieodłącznej korzyści ani wady dla żadnego z nich, o ile te role i roszczenia mają zasięg lokalny. Ale jeśli, na przykład, autoryzacja zależy od zewnętrznych oświadczeń dotyczących tożsamości, wtedy role będą nieodpowiednie. Musisz zaakceptować roszczenie zewnętrzne i przetłumaczyć je na rolę o zasięgu lokalnym. Niekoniecznie jest w tym nic złego, ale wprowadza warstwę pośrednią i odrzuca kontekst.

Szerzej, należy rozważyć kontrolę dostępu opartą na atrybutach (ABAC). RBAC i ABAC to pojęcia zdefiniowane przez NIST, Narodowy Instytut Norm i Technologii. Z drugiej strony CBAC to model forsowany przez Microsoft, który jest bardzo podobny do ABAC.

Przeczytaj więcej tutaj:

• Kontrola dostępu oparta na rolach Strona NIST
• Strona NIST kontroli dostępu oparta na atrybutach

Podstawą między RBAC i CBAC jest to, że:

RBAC : użytkownik musi mieć przypisaną rolę, aby uzyskać uprawnienia do wykonywania czynności.

CBAC : użytkownik musi mieć roszczenie o poprawnej wartości, zgodnie z oczekiwaniami aplikacji, aby uzyskać autoryzację. Kontrola dostępu oparta na oświadczeniach jest elegancka do pisania i łatwiejsza w utrzymaniu.

Poza tym oświadczenia są wystawiane do aplikacji przez wystawiające usługi autoryzacyjne (Security Service Token STS), które są zaufane przez Twoją aplikację (strona ufająca)

Rola to tylko jeden rodzaj roszczenia. W ten sposób może istnieć wiele innych typów roszczeń, na przykład nazwa użytkownika jest jednym z typów roszczeń

Ważne jest, aby najpierw przeanalizować, do czego jest wymagane uwierzytelnianie, zanim zdecydujesz, która metoda jest najlepsza. W poniższej dokumentacji firmy Microsoft jest napisane „Roszczenie nie jest tym, co podmiot może zrobić. Na przykład możesz mieć prawo jazdy wydane przez lokalny urząd ds. Praw jazdy. Twoje prawo jazdy zawiera datę urodzenia. W takim przypadku nazwa roszczenia byłaby DateOfBirth, wartością roszczenia byłaby Twoja data urodzenia, na przykład 8 czerwca 1970 r., a wystawcą byłby urząd ds. praw jazdy. Autoryzacja oparta na roszczeniach w najprostszy sposób sprawdza wartość roszczenia i umożliwia zasób oparty na tej wartości. Na przykład, jeśli chcesz uzyskać dostęp do klubu nocnego, proces autoryzacji może wyglądać następująco: 6 "

Z tego przykładu widzimy, że dostęp do klubu nocnego z autoryzacją opartą na roszczeniach jest inny niż typ autoryzacji, który będzie wymagany przez personel pracujący w klubie nocnym, w tym przypadku personel klubu nocnego będzie wymagał autoryzacja oparta na rolach, która nie jest wymagana dla odwiedzających klub nocny, ponieważ wszyscy goście klubu nocnego mają wspólny cel w klubie nocnym, dlatego w tej sytuacji upoważnienie oparte na roszczeniach jest odpowiednie dla odwiedzających klub nocny.

Autoryzacja oparta na rolach https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 Po utworzeniu tożsamości może ona należeć do jednej lub więcej ról. Na przykład Tracy może należeć do ról administratora i użytkownika, podczas gdy Scott może należeć tylko do roli użytkownika. Sposób tworzenia tych ról i zarządzania nimi zależy od magazynu zapasowego procesu autoryzacji. Role są udostępniane deweloperowi za pomocą metody IsInRole w klasie ClaimsPrincipal.

Autoryzacja oparta na https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims oświadczeniach 14.10.2016 Po utworzeniu tożsamości można do niej przypisać jedno lub więcej oświadczeń wystawionych przez zaufaną stronę. Oświadczenie to para-wartość nazwa, która reprezentuje to, czym jest podmiot, a nie to, co podmiot może zrobić. Na przykład możesz mieć prawo jazdy wydane przez lokalny urząd ds. Praw jazdy. Na prawie jazdy znajduje się Twoja data urodzenia. W tym przypadku nazwa roszczenia byłaby DateOfBirth, wartością roszczenia byłaby Twoja data urodzenia, na przykład 8 czerwca 1970 r., A wystawcą byłby organ prawa jazdy. Autoryzacja oparta na oświadczeniach w najprostszej postaci sprawdza wartość oświadczenia i umożliwia dostęp do zasobu opartego na tej wartości. Na przykład, jeśli chcesz uzyskać dostęp do klubu nocnego, proces autoryzacji może wyglądać:

Przed udzieleniem dostępu pracownik ochrony drzwi oceni wartość Twojego roszczenia z tytułu daty urodzenia i czy ufa wystawcy (organowi ds. Praw jazdy).

Tożsamość może zawierać wiele oświadczeń z wieloma wartościami i może zawierać wiele oświadczeń tego samego typu.

Możliwe jest również zarządzanie rolami w sposób roszczeniowy.

Zamiast tworzyć role autoryzacyjne, które odzwierciedlają rolę biznesową, utwórz role, które odzwierciedlają role akcji, np. CreateCustomer, EditCustomer, DeleteCustomer. Opisz metody zgodnie z wymaganiami.

Odwzorowanie osób na zestaw ról w działaniu nie jest prostą sprawą, zwłaszcza że lista ról staje się coraz większa. Dlatego musisz zarządzać rolami biznesowymi na niższym poziomie szczegółowości (np. Sprzedaż, marketing) i mapować rolę biznesową do wymaganych ról czynności. Oznacza to, że dodaj użytkownika do roli biznesowej i odwzorowuje go na wymagane role (działania) w istniejącej tabeli autoryzacji.

Możesz nawet zastąpić rolę biznesową i bezpośrednio dodać osobę do roli akcji.

Ponieważ tworzysz na podstawie tego, co już działa, nie cofasz istniejącego procesu autoryzacji. Aby zaimplementować to podejście, potrzebujesz tylko kilku tabel

Myślę, że na to pytanie można odpowiedzieć z perspektywy bazy danych. jeśli zauważyłeś, w jaki sposób tabele związane z tą implantacją, znajdziesz następujące

1. AspNetUsers: każdy użytkownik ma jeden wiersz ze wszystkimi atrybutami wymaganymi przez wszystkich użytkowników, takimi jak adres e-mail, adres, telefon, hasło .....
2. AspNetRoles; definiuje różne role zgodnie z wymaganiami aplikacji, takimi jak GM, CTO, HRM, ADMIN, EMP. to, co definiuje każda rola, jest zgodne z potrzebami aplikacji.
3. AspNetUserRoles: każdy wiersz łączy AspNetUsers i AspNetRoles oraz skutecznie łączy jednego użytkownika z wieloma rolami.
4. AspNetUserClaims: każdy wiersz ma klucz do AspNetUsers oraz jeden typ i wartość. tak efektywnie dodaj jeden atrybut dla każdego użytkownika, który można dodać / usunąć w czasie wykonywania.

Korzystanie z tych tabel można dostosować w jednym momencie życia użytkownika / aplikacji, aby dopasować je do określonych potrzeb.

Rozważmy wczesny etap „Kierownika ds. Zakupów” (PM), możemy przyjąć trzy podejścia

1. Aplikacja wypełnia AspNetUserRoles jednym wierszem, aby przyznać „PM” prawo do zakupu. Aby wystawić zamówienie na dowolną kwotę, użytkownik potrzebuje tylko roli „PM”.

2. Aplikacja wypełnia AspNetUserRoles jednym wierszem, aby przyznać „PM” prawo do kupowania, i wypełnia AspNetUserClaims roszczenie typu „Kwota zakupu” typu TYP i wartość „<1000”, aby ustawić limit kwoty. Aby wystawić zamówienie, użytkownik musi mieć „PM”, a kwota zamówienia jest mniejsza niż wartość roszczenia TYP „Kwota zakupu”.

3. Aplikacja wypełnia AspNetUserClaims oświadczeniem TYPE „Kwota zakupu” i wartością „<1000”. Każdy użytkownik może wystawić zamówienie, pod warunkiem, że kwota jest niższa niż wartość roszczenia TYP „Kwota do zakupu” dla tego użytkownika.

Jak można było zauważyć, role based to zgrubne, sztywne uprawnienia, które uprościłyby życie użytkownika aplikacji z punktu widzenia zarządzania systemem. jednakże ograniczy to możliwości użytkownika z punktu widzenia wymagań biznesowych. Z drugiej strony oparte na roszczeniach to bardzo dobre prawa, które należy przypisać każdemu użytkownikowi. Na podstawie roszczeń również firma przesunie granice, jednak bardzo skomplikuje zarządzanie systemem.

Kontrola dostępu oparta na rolach (RBAC)

W swojej organizacji możesz pełnić następujące role

Pracownik

Menedżer

HR

W zależności od roli lub ról, do których należy zalogowany użytkownik, możesz autoryzować dostęp do niektórych zasobów w aplikacji lub nie. Ponieważ używamy ról do sprawdzania autoryzacji, jest to powszechnie nazywane kontrolą dostępu opartą na rolach (RBAC) lub autoryzacją opartą na rolach.

W ASP.NET Core do implementacji autoryzacji opartej na rolach używamy atrybutu Autoryzuj z parametrem Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Kontrola dostępu oparta na oświadczeniach (CBAC)

CO to jest roszczenie? Oświadczenie to para nazwa-wartość. To tak naprawdę informacja o użytkowniku, a nie o tym, co użytkownik może, a czego nie może zrobić. Na przykład nazwa użytkownika, adres e-mail, wiek, płeć itp. Są roszczeniami. Sposób wykorzystania tych oświadczeń do kontroli autoryzacji w aplikacji zależy od działalności aplikacji i wymagań dotyczących autoryzacji.

Na przykład, jeśli tworzysz portal dla pracowników, możesz zezwolić zalogowanemu użytkownikowi na złożenie wniosku o urlop macierzyński, jeśli wartość roszczenia dotycząca płci to kobieta. Podobnie, jeśli tworzysz aplikację e-commerce, możesz zezwolić zalogowanemu użytkownikowi na złożenie zamówienia, jeśli wartość roszczenia wiekowego jest większa lub równa 18.

Roszczenia są oparte na zasadach. Tworzymy polisę i dołączamy do niej jedno lub więcej roszczeń. Zasady są następnie używane wraz z parametrem zasad atrybutu Autoryzuj w celu zaimplementowania autoryzacji opartej na oświadczeniach.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}