Jak zaprojektować kontrolę dostępu opartą na rolach?

Próbuję podążać za modelem kontroli dostępu opartym na rolach, aby ograniczyć to, co użytkownicy mogą lub nie mogą robić w moim systemie.

Do tej pory mam następujące podmioty:

users - Ludzie, którzy będą korzystać z systemu. Tutaj mam nazwy użytkownika i hasła. role - zbiór ról, które mogą mieć użytkownicy. Rzeczy takie jak zasoby menedżera, administratora itp. - Rzeczy, którymi użytkownicy mogą manipulować. Jak kontrakty, użytkowników, przeciągi kontraktowy itp operacje - rzeczy, które użytkownik może zrobić z zasobów. Jak tworzyć, czytać, aktualizować lub usuwać.

Teraz moje wątpliwości pojawiają się tutaj na schemacie, na którym mam taką relację:

operacje (0 .. *) są wykonywane na zasobach (0 .. *), które generują tabelę, którą nazwałem uprawnieniami, i która przechowuje operację i zasób .

Tabela uprawnień będzie wyglądać następująco (jeden wiersz): ID: 1, operacja: tworzenie, zasób: umowa.

Co oznacza uprawnienie do tworzenia się kontrakt .

Zrobiłem to w ten sposób, ponieważ uważam, że niektóre zasoby mogą nie mieć wszelkiego rodzaju operacji. Na przykład w celu zarejestrowania umów użytkownicy mogą przesyłać pliki , ale ta operacja nie jest dostępna w celu rejestracji dostawcy .

Dlatego teraz, gdy administrator będzie udzielał uprawnień do roli , nie będzie miał listy zasobów z każdą zarejestrowaną operacją w systemie.

Myślę, że każdy zasób ma własną kolekcję operacji, które można na nim wykonać.

Mogę wyjaśnić, czy coś nie jest zrozumiałe.

Czy to jest właściwy sposób na wdrożenie RBAC?

EDYTOWAĆ

Mam na myśli to, że mając tabelę uprawnień zawierającą operacje i zasoby , mam DWIE dodatkowe tabele, ponieważ chcę powiązać zasoby z operacjami . Mógłbym także zrobić zasoby, które mają uprawnienia, w których tabela uprawnień przechowywałaby uprawnienia.

Ale wtedy stałoby się tak, że niektóre uprawnienia, które nawet nie istnieją dla niektórych zasobów, pojawiałyby się, gdy administrator je przypisywał.

Więc chcę wiedzieć z punktu widzenia projektu bazy danych, czy to uprawnienie do tabeli, które ma operację na jednej kolumnie i inny zasób jest poprawne? Czy napotkam problemy, jeśli tak pozostanie?

Twój projekt wydaje mi się bardzo bliski. Tylko kilka sugestii.

users - Ludzie, którzy będą korzystać z systemu. Tutaj mam nazwy użytkownika i hasła.

W porządku

role - zbiór ról, które mogą mieć użytkownicy. Rzeczy takie jak menedżer, administrator itp.

Też dobrze. Ale będziesz także potrzebował encji / tabeli „UserRoles”, która powie ci, którzy użytkownicy pełnią role. Prawdopodobnie dany użytkownik może mieć dwie lub więcej ról.

zasoby - rzeczy, którymi użytkownicy mogą manipulować. Podobnie jak umowy, użytkownicy, projekty umów itp.

Może to być tylko kwestia semantyki. Nie sądzę, aby użytkownicy bezpośrednio manipulowali zasobami; role robią. W ten sposób przechodzi użytkownik -> rola użytkownika -> rola -> operacja -> zasób

operacje - rzeczy, które użytkownicy mogą zrobić z zasobami. Jak tworzyć, czytać, aktualizować lub usuwać.

tak, z wyjątkiem „ról” zamiast „użytkowników”

Tabela uprawnień będzie wyglądać następująco (jeden wiersz): ID: 1, operacja: tworzenie, zasób: umowa. Co oznacza pozwolenie na utworzenie umowy.

Hmmm. Można to zrobić na dwa sposoby. Możesz mieć opisaną tabelę uprawnień, ale potrzebujesz także dodatkowej RolePermissionstabeli / encji, która powie ci, która rola ma uprawnienia. Ale nie jestem pewien, czy jest to konieczne.

Prostszym sposobem na to jest tabela uprawnień / jednostka z następującymi kolumnami / atrybutami: identyfikator roli, identyfikator operacji, identyfikator zasobu. W ten sposób operacje x kombinacje zasobów są przypisywane bezpośrednio do roli, a nie ładowane do uprawnienia przypisanego do roli. Eliminuje jeden byt. Naprawdę nie ma potrzeby oddzielnej tabeli uprawnień niezależnych od roli, chyba że chcesz wstępnie zdefiniować, które kombinacje uprawnień są dozwolone, a które nie.

Nie używałbym ani nie implementował RBAC. Zamiast tego użyłbym ABAC. Pozwól mi wyjaśnić...

• RBAC lub kontrola dostępu oparta na rolach dotyczy zarządzania użytkownikami i przypisywania ról. W RBAC możesz powiedzieć, że Alice jest menedżerem. Jednocześnie możesz zdefiniować uprawnienia statyczne. Na przykład kierownik może zatwierdzać pożyczki. Jest więc link od Alicji do menedżera, aby zatwierdzić Loan jako pozwolenie. Istnieje wiele systemów, które pozwolą ci to zrobić, więc nie musisz implementować własnych tabel. Nawet LDAP obsługuje ograniczone zestawy RBAC. Jest to w porządku, o ile masz stosunkowo niewielki zestaw ról i uprawnień. Ale co, jeśli chcesz wziąć pod uwagę określone uprawnienia, tak jak w twoim przypadku? Wyświetl, usuń, wstaw? Co jeśli chcesz wziąć pod uwagę relacje?
• ABAC lub kontrola dostępu oparta na atrybutach dotyczy precyzyjnej autoryzacji opartej na zasadach. Za pomocą ABAC możesz używać ról zdefiniowanych w RBAC i zapisywać polityki np
  • Menedżerowie mogą przeglądać dokumenty w swoim dziale
  • Pracownicy mogą edytować posiadane dokumenty

W swoim pytaniu zasadniczo zdefiniowałeś model informacyjny. Twoje obiekty i ich atrybuty, np. Użytkownik (nazwa, hasło, dział ...); przedmiot (np. umowa) i tak dalej.

W ABAC całkowicie oddzielisz kod / logikę aplikacji od logiki autoryzacji, która jest następnie przechowywana jako zasady przy użyciu atrybutów. Same uprawnienia są przechowywane bezpośrednio w zasadach (patrz przykład powyżej). Architektura wdrażania ABAC wygląda następująco

Chodzi o to, że jeśli podejmiesz podejście ABAC, napiszesz zasady dla ABAC (w XACML lub ALFA - jest do tego mnóstwo narzędzi) i nigdy nie będziesz musiał ponownie tworzyć niestandardowego kodu RBAC ani kontroli dostępu.