Mikroserwisy a autoryzacja

Temat dość gruby.
Przechodzimy z wielkiego monolitu na mikro.
Chciałbym się spytać jak u Was wyglada kwestia zarządzania uprawnieniami. Dajmy ze jest 10 domen i pytanie czy w każdej domenie można autonomicznie parametryzować dostęp klienta do produktu?

Czy istnieje jedna domena parametryzujaca uprawnienia klienta?

U mnie jest dość prosto. AGW dostaje token JWT uwierzytelniający żądanie, dorzuca nagłówek z uprawnieniami (kiepskie rozwiązanie, ale akurat w tym przypadku konieczne), dopisuje do nagłówka każdego żądania role użytkownika i wysyła dalej. Usługi za AGW odpowiadają za autoryzację, czyli sprawdzają czy konkretna rola (albo użytkownik) ma prawo wywołać konkretną akcję w usłudze. Jeżeli potrzebne jest wykonanie dodatkowego zapytania, to nagłówek z AGW jest do niego dołączany. Jak coś nie pasuje, to któraś usługa zwraca 403, które leci sobie łańcuszkiem z powrotem do klienta, który zainicjował żądanie.

@piotrpo: tylko ze tu jest właśnie minus który widzę.
IMO upraszczając to biznesowe serwisy powinny robić tylko biznesowe rzeczy. Authorization jest rzeczą techniczna. Konieczna jest sepracja. W obecnym projekcie zaproponowałem rozwiązanie gdzie auth server enkapsulowalby uprawnienia. Wyglądałoby to tak seq:

1. Apigtw dostaje usera i przedmiot na którym user działa. Np „Jako klient X załóż lokatę o wysokości y”
2. Apigtw nie wie, wiec uderza do auth serv. Tutaj dokonywany jest cały proces sprawdzenia uprawnień
3. Apigtw dostaje odp czy może przesłać do domeny czy nie.

Chciałem zapytać co o tym sądzicie?

@DKN: Moim zdaniem trochę zbyt skomplikowane. Ostatecznie też sprawdzasz w tym docelowym serwisie uprawnienia, tylko nie odczytujesz ich z samego requesta, a z jakiegoś dodatkowego zewnętrznego API.

Przede wszystkim to jak wspomniał już słusznie @piotrpo JWT jest tutaj kluczem. Natomiast co do tego:

IMO upraszczając to biznesowe serwisy powinny robić tylko biznesowe rzeczy.

Serwisy powinny być wewnętrznie podzielone na warstwy, dzięki czemu warstwa aplikacji może zająć się uwierzytelnianiem i autoryzacją. Logika biznesowa pozostaje wtedy nietknięta, bo to czy ktoś może wykonać daną operację sprawdzi warstwa aplikacja- web API etc.

Co do JWT to się zgadzam, ze on zawsze jest kluczem, czyli nośnikiem informacji, to z niego są wyciągane potrzebne info do autoryzacji.

To ze aplikacje są podzielone na warstwy to tez sprawa jasna. Jednak są pewne rzeczy które są problemem.
Dajmy ze są 2 poziomy granulacji:
Domena (zbiór subdomen, np. Domena ranskacji. Domena Klient..)
Subdomna/Mikroserwis (np, w domenie klienta będziemy miec osobne mikroserwisy. mikroserwis dla ankiet dla klienta, mikroserwis dla utrzymiwania podstawowych info o kliencie, mikroserwis do walidacji dowodów osobistych z baza MSW itd..)

Wprowadzając koncepcje gdzie każdy mikroserwis musi trzymać odp. za autoryzacje zmuszamy by każdy zespół brał na siebie bezpieczeństwo.

We wcześniejszym poście chciałem przekazać ze chodzi mi by oddzielić kwestie techniczne i biznesowe, przez odpowiednie routowanie ruchu. Czyli stworzenia warstwy filtracji na poziomie APIGTW, który by rozmawiał z jednym serwisem autoryzacyjnym w domenie.

To już zależy czy uważasz to za problem, czy też nie. Dla mnie to jednak trochę wyolbrzymianie problemu bo kwestia autoryzacji w oparciu o JWT to zazwyczaj tylko kwestia podpięcia odpowiedniej biblioteki/frameworku. Można to nawet jeszcze bardziej uprościć pakując to w wewnętrzną paczkę używaną przez wszystkie serwisy.

Ewentualnie, jeśli masz taki klaster serwisów odpowiedzialny za konkretny konkursy biznesowy, to można postawić przed nimi API gateway i tam sprawdzać autoryzację.

@DKN: To niesie ze sobą bardzo spory problem, API Gateway, który powinien odpowiadać jedynie za routing, nagle musi wiedzieć kto może obsłużyć konkretne żądania. Jeżeli te uprawnienia da się rozwiązać na poziomie endpointów - luzik, da się zrobić. Co jeżeli, będziesz musiał rozróżniać uprawnienia na poziomie konkretnych encji? Np. wniosek urlopowy zatwierdza manager, ale tylko w odniesieniu do swoich podwładnych? Będziesz sprawdzał, czy w jakimś post /requests/1234/acceptance jest w strukturze organizacyjnej powiązanie pomiędzy autorem wniosku 1234 a managerem odczytanym z JWT?

Możesz to zrobić te w ten sposób, że API Gateway przekieruje idący z zewnątrz JWT, lub go zastąpi czymś własnym (jesteśmy już w wewnętrznych sieciach, możemy sobie w miarę ufać) i w ostateczności serwis docelowy dostaje jakiś nagłówek:

{
userName=Kowalski,
roles:
  [EMPLOYEE, MANAGER]
}

Samo sprawdzenie czy JWT jest w porządku dalej przeprowadza się na poziomie ApiGtw, natomiast potwierdzenie uprawnień do zasobu tam gdzie się ten zasób trzyma.

@piotrpo: API gateway to taka nazwa umowna, można to nazwać inaczej. Poza tym nie jest prawdą, że API gateway służy tylko do routingu. Chociażby agregacja danych z kilku źródeł i zwrócenie do klienta często również leży w gestii takiego serwisu. Jeśli więc byłaby taka potrzeba, to nie widzę przeszkód aby mieć taki serwis odpowiadający za uwierzytelnianie i autoryzację. Bądźmy pragmatyczni.

Zwróć uwagę że są usługi takie jak np. Azure API Management, który również jest jakby API gateway i serwisem uwierzytelniajacym w jednym.

@Aventus: Jeżeli Rolą serwisu jest agregacja danych z kilku serwisów i wysyłanie ich na zewnątrz, to nie jest API Gateway. Nie żeby było to coś złego, ale w dyskusji warto używać precyzyjnych sformułowań. OP rozczłonkowuje jakiś monolit. Ma do tego z grubsza 2 możliwe podejścia:

• Postawić API Gatweay, wydzielać kawałki domeny (po istniejących endpointach) i w miarę postępu przepinać pojedynczo ścieżki na inne serwisy. W tym przypadku warto mieć bardzo ograniczoną odpowiedzialność API Gateway, bo to pozwala na utrzymanie większej otwartości na zmiany i przy okazji ogranicza ryzyko, że coś walnie. Jeżeli wrzucisz dużą odpowiedzialność do API Gateway, to musisz dokonywać tam zmian przy wielu okazjach, czyli tracisz/ograniczasz jeden z większych atutów architektury uS, czyli ograniczony zakres zmian.

• Zostawić ten serwis, razem z publicznym API i wyciągać poszczególne kawałki gdzieś dalej. Też niby można, ale łatwo nie będzie.

  Podobnie, używając argumentu "pragmatyczności", można uznać, ze po co dzielić serwis na warstwy, jak właściwie wszystko da się zaimplementować na widoku. Moim zdaniem podobna sytuacja.