Ważną częścią zabezpieczeń każdej platformy (PaaS) w zakresie uwierzytelniania jest możliwość ograniczenia i/lub zdefiniowania "uprawnień" lub uprawnień konkretnego użytkownika lub aplikacji lub użytkownika na podstawie danych użytkownika/aplikacji lub na podstawie uwierzytelnienia.Architektura modelu autoryzacji autoryzacji platformy
Typowy model uprawnień w nowoczesnych platformach lub interfejsach API produktu oparty jest na koncepcji "Zakresy". W moich badaniach wszyscy używają tego stylu modelowania uprawnień w swoich implementacjach OAuth. Jednak wydaje się, że ten model "zakresów" dotyczy jedynie tego, w jaki sposób aplikacje zewnętrzne (tj. Strony trzecie) uzyskują dostęp do danych uwierzytelnionego użytkownika.
Wewnętrznie modele uprawnień wydają się być bardziej skoncentrowane na modelu opartym na roli (administrator, moderator, użytkownik itd.) Lub na wielu innych niestandardowych implementacjach.
Moje pytanie brzmi następująco: "Jaki model uprawnień najlepiej pasuje do nowoczesnego systemu PaaS, który chciałby ograniczyć jego użytkowników do określonych działań ORAZ ograniczyć dostęp aplikacji zewnętrznych do danych użytkownika i jak można go zaprojektować w sposób na świadomy wydajności? "
Moje wstępne badania doprowadziły mnie do wewnętrznego i zewnętrznego użycia modelu uprawnień opartego na zakresie. Niestety, projektowanie takiego systemu nie jest banalne. Widziałem wiele metod tworzenia takiej architektury:
AR-przyjazny relacyjnej DB sposób:
tworzenia wielu tabel z łączenia tabel dla wielu do wielu relacji między lista uprawnień, dostępne uprawnienia użytkownika, token użytkownika i aktywne uprawnienia tokena użytkownika.
Użytkownik może uwierzytelnić token i określić jak wiele uprawnień, aby być dostępne na tokenu do uprawnieniami pierwotnie ustalonych dla danego użytkownika
mądry bit maskowania sposób:
pomocą prostego kolumnę całkowitą w zbiorze danych do przechowywania wartość całkowitą
Wartość całkowita jest dostępna w sposób binarny, wykorzystując operatory bitowe ustawić, get, przełącznik (ETC) uprawnienia użytkownika lub ich tokena przez co stanowi zgodę jako pojedynczy bit
Wydaje się, że każdy z nich ma swoje zalety i wady. Metoda przyjazna dla AR wydaje się być bardzo elastycznym rozwiązaniem, ale wydaje się również, że może być poważnym działaniem, ponieważ wiele połączeń/zapytań musiałoby zostać uruchomionych, a instancje modelu ORM musiałyby zostać utworzone na przy każdym uwierzytelnionym wywołaniu . Sposób maskowania bitów wydaje się być bardzo szybki i wydajny, ale byłby mniej intuicyjny w opracowywaniu i byłby bardziej podatny na błędy.Ponadto, maskowanie bitowe wydaje się być rozwiązaniem ograniczającym, ponieważ łatwo byłoby pozwolić na bardzo "binarny" model uprawnień (może lub nie może być) bez medium-medium/happy-medium, a to ograniczyłoby uprawnienia do twardy 64-bitowy limit oparty na ograniczeniach sprzętowych.
Czy brakuje innej metody modelowania lub architektury uprawnień, o której mi chodzi? Czy jestem na dobrej drodze, a rozważania dotyczące wydajności nie są aż tak wielkim problemem (jeśli chodzi o metodę relacji), tak jak to robię?
Dziękuję bardzo!
tl; dr:
Co pozwolenie modelu najlepiej pasuje do nowoczesnych PaaS, które chciałyby zarówno ograniczyć jego użytkowników od pewnych działań i ograniczyć aplikacji 3rd party z dostępu do danych użytkownika i jak to może być architekturę w sposób na świadomy wydajności?
Jeśli chodzi o wydajność to dotyczy, czy pomyślałeś o użyciu sklep klucz/wartość, takich jak Redis do przechowywania danych uprawnień? –
Tak, pomyśleliśmy o tym. Ale dzięki @DavidAllen, to zdecydowanie dobry pomysł. Zastanawiamy się nad wymieszaniem dwóch wzorów dla szczęśliwego medium. Zrobię zapis, gdy tylko pomysł zostanie "upieczony". : D – Rican7