Autoryzacja użytkownika za pomocą mikrousług

12

Czy mikrousługi powinny być odpowiedzialne za obsługę własnej autoryzacji, czy uważasz, że lepiej jest mieć oddzielną usługę autoryzacji, która jest wspólna dla wszystkich lub podzbioru (w tej samej domenie biznesowej) mikrousług?

Dla mnie to drugie ma większy sens, ponieważ ułatwia stosowanie zmian, egzekwowanie zasad; jest SUCHY itp. Jednak może łatwo wymknąć się spod kontroli przez wszelkiego rodzaju usługi, które zrzucają swoje reguły w jedno miejsce, a także obawia się o obciążenie sieci.

jakieś pomysły?

architecture authorization microservices

— morcmarc
źródło

7

Użyłbym centralnego, zunifikowanego systemu uwierzytelniania i miałbym osobne uprawnienia / statystyki dla każdej mikrousługi (coś w rodzaju, jak nie mogę jeszcze głosować na tej stronie wymiany stosów, ale mogę przepełnić stos podczas korzystania z centralnego systemu uwierzytelniania wymiany stosów). Jeden z moich obecnych projektów będzie wykorzystywał to podejście w najbliższej przyszłości, co będzie miłe; poprzednie prace rozwojowe obejmowały stworzenie systemu zgodnego z HIPPA, wymagającego drugiego poziomu autoryzacji / uwierzytelnienia, i jest czasochłonne irytujące dla szeregowego autoryzowania łańcuchów z prawnie oddzielnych, ale funkcjonalnie nierozdzielnych elementów systemu. Proces debugowania wymaga o wiele mniej radości niż zwykłe logowanie lub interfejs API z nagłówkami appid i x-auth.

Które użyć zależy od konkretnych wymagań planu rozwoju, ale wybrałbym tam, gdzie to możliwe, prostsze podejście, aby uniknąć nadmiernych kosztów ogólnych i czasu / wysiłku rozwojowego.

— Jonathan Voss
źródło

Używamy OAuth2 do uwierzytelniania i chciałbym przestrzegać tej samej zasady - to znaczy mieć centralną usługę z jedną, ściśle określoną odpowiedzialnością - za autoryzację, zamiast powielać funkcjonalność i logikę rozproszoną między usługami. Dla mnie jest to naruszenie granicy domeny. Zgadzam się jednak, że oznacza to, że będziemy musieli rozwiązać izolację reguł serwisowych (ala stackoverflow, programiści itp.).

— morcmarc

2

Możliwe, że masz globalne uprawnienia, które są unieważniane przez uprawnienia specyficzne dla usługi, przydatne, jeśli garść podstawowych mikrousług korzysta z tych samych uprawnień. Uprawnienia tej mikrousługi powinny być prawdopodobnie przechowywane w infrastrukturze aplikacji dla tej mikrousługi, aby uniknąć potencjalnych problemów z wydajnością centralnej usługi uwierzytelniania.

— Jonathan Voss,

4

Każda mikrousługa nie powinna wykonywać własnego uwierzytelnienia, ale musi wykonywać własną autoryzację.

Źródło

I to ma sens. Zakładam, że nie ma wątpliwości co do centralnego uwierzytelnienia. Ale autoryzacja jest dość myląca.

Biorąc pod uwagę, że liczba mikrousług może wzrosnąć do setek, tysięcy, centralna usługa autoryzacji powinna być odpowiedzialna tylko za wyświetlanie uprawnień, ale nie za ich sprawdzanie. Poszczególne mikrousługi mogą wymagać innego podejścia w celu potwierdzenia uprawnień.

Ta centralna usługa autoryzacji może wymagać modeli z różnych usług i inaczej podejść do podjęcia decyzji, na początku może wydawać się łatwa i ładna. Ale później może być chaos.

— Ashwani Agarwal
źródło