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?
źródło
Odpowiedzi:
Twój projekt wydaje mi się bardzo bliski. Tylko kilka sugestii.
W porządku
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.
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
tak, z wyjątkiem „ról” zamiast „użytkowników”
Hmmm. Można to zrobić na dwa sposoby. Możesz mieć opisaną tabelę uprawnień, ale potrzebujesz także dodatkowej
RolePermissions
tabeli / 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.
źródło
Nie używałbym ani nie implementował RBAC. Zamiast tego użyłbym ABAC. Pozwól mi wyjaśnić...
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.
źródło