Obecnie buduję system oparty na mikroserwisach na Java Spring Cloud. Niektóre mikroserwisy korzystają z PostgreSQL i niektórych z nich MongoDB. REST i JMS służą do komunikacji. Plan polega na użyciu SSO i OAuth2 do uwierzytelnienia.Autoryzacja w mikroserwisach - jak podejść do kontroli dostępu do obiektu domeny lub poziomu podmiotu za pomocą listy ACL?
Wyzwanie, przed którym stoję, polega na tym, że autoryzacja musi zostać wykonana na poziomie obiektu/podmiotu domeny. Oznacza to, że potrzebna jest jakaś lista ACL (Access Control List). Najlepszą praktyką w tego rodzaju architekturze jest unikanie czegoś takiego i posiadanie gruboziarnistego zabezpieczenia prawdopodobnie na poziomie warstwy aplikacji/usługi w każdym mikroserwisie, ale niestety nie jest to możliwe.
Mój ostatni pomysł to użycie ACL Spring Security i posiadanie tabel ACL we wspólnej bazie danych pomiędzy wszystkimi mikroserwisami. Dostęp do bazy danych miałby tylko infrastruktura Spring lub Spring API. Schemat DB wygląda stabilnie i jest mało prawdopodobny. W tym przypadku po prostu złamałbym zasadę dzielenia się db między mikroserwisami.
Rozważałem różne rodzaje rozproszonych rozwiązań, ale opuścił je:
- Jeden microservice z ACL i dostępu do niego za pomocą resztę - Problemem jest zbyt wiele połączeń HTTP i obniżenie wydajności. Musiałbym rozszerzyć ACL Spring Security, by zastąpić dostęp do bazy danych przez wywołania reszta
- ACL w każdej mikroserwisie dla własnych jednostek - Brzmi całkiem rozsądnie, ale wyobraź sobie, że przypadek ma kilka odczytanych modeli podmiotów zsynchronizowanych z niektórymi innymi mikroserwisami lub tą samą jednostką, która istnieje w różnych ograniczonych kontekstach (różne mikrousługi). Listy ACL mogą stać się naprawdę niemożliwe do kontrolowania i mogą być źródłem błędów.
- Jedna usługa mikro z tabelami ACL, które są synchronizowane z innymi mikroserwisami jako model odczytu. Problem polega na tym, że nie ma wsparcia w ACL Spring Security dla MongoDB. Widziałem kilka niestandardowych rozwiązań na Github i tak jest wykonalne. Ale ... podczas tworzenia nowego obiektu muszę utworzyć rekord w mikroserwisie, który jest właścicielem listy ACL, a następnie jest asynchronicznie synchronizowany jako model odczytu do mikroserwisu będącego właścicielem encji. To nie brzmi jak łatwe rozwiązanie.
- Wybierz kontrolę dostępu opartą na adresie URL na bramie API. Ale musiałbym jakoś zmodyfikować ACL Spring Security. Brama API musiałaby wiedzieć zbyt wiele o innych usługach. Ziarnistość kontroli dostępu jest związana z ziarnistością interfejsu API REST. Może nie mogę sobie wyobrazić wszystkich konsekwencji i innych problemów, które spowodowałyby to podejście. Ostatecznie rozwiązanie z udostępnionym db, o którym wspomniałem, jest moim ulubionym. W rzeczywistości był to pierwszy dyskwalifikacja, ponieważ jest to "udostępniona" baza danych. Ale po przejściu przez możliwości wydawało mi się, że to jedyny, który zadziała. Dodatkowa złożoność jest nieco bardziej skomplikowana, ponieważ chciałbym użyć buforowania, ponieważ potrzebna byłaby rozproszona pamięć podręczna.
Naprawdę skorzystam z porad i opinii, jak podejść do architektury, ponieważ jest to bardzo trudne i wiele rzeczy może pójść nie tak.
Dziękujemy,
Lukas
Rozważam również to podejście. Teraz szukam internetowej aplikacji bibliotecznej, która zapewni GUI administratora ACL. Jak się masz? Wszystko samemu? – Adam
Cóż, w końcu przecież opuściłem listy ACL i zrobiłem proste rozszerzenie dla Spring, które pozwoliło mi przejść bez trwałości informacji o dostępie do obiektu. Po dalszych dyskusjach z właścicielami produktów odkryliśmy, że istnieje sposób na rozwiązanie tego problemu za pomocą pewnej "logiki bezpieczeństwa". Z mojego punktu widzenia zawsze jest lepiej, jeśli to możliwe. Inną rzeczą jest to, że Spring oferuje narzędzia do oceny za pomocą ACL, ale nie ma narzędzi, które pomagałyby ustawić lub zaktualizować tabele ACL –