Strategia uwierzytelniania mikrousług

138

Trudno mi wybrać przyzwoitą / bezpieczną strategię uwierzytelniania dla architektury mikrousług. Jedyny post SO, jaki znalazłem na ten temat, to ten: Single Sign-On in Microservice Architecture

Moim pomysłem jest posiadanie w każdej usłudze (np. Uwierzytelnianie, przesyłanie wiadomości, powiadomienie, profil itp.) Unikalnego odniesienia do każdego użytkownika (całkiem logicznie niż jego user_id) i możliwość uzyskania aktualnego użytkownika, idjeśli jest zalogowany.

Z moich badań wynika, że ​​istnieją dwie możliwe strategie:

1. Architektura współdzielona

Wspólna architektura

W tej strategii aplikacja uwierzytelniająca jest jedną z usług. Ale każda usługa musi mieć możliwość wykonania konwersji session_id=>, user_idwięc musi być śmiertelnie prosta. Dlatego pomyślałem o Redisie, który przechowywałby klucz: wartość session_id:user_id.

2. Architektura zapory

Architektura zapory

W tej strategii przechowywanie sesji nie ma tak naprawdę znaczenia, ponieważ jest obsługiwane tylko przez aplikację uwierzytelniającą. Następnie user_idmożna je przekazać do innych usług. Pomyślałem o Rails + Devise (+ Redis lub pamięć podręczna lub przechowywanie plików cookie itp.), Ale jest mnóstwo możliwości. Liczy się tylko to, że Service X nigdy nie będzie musiał uwierzytelniać użytkownika.


Jak wypada porównanie tych dwóch rozwiązań pod względem:

  • bezpieczeństwo
  • krzepkość
  • skalowalność
  • łatwość użycia

A może zasugerowałbyś inne rozwiązanie, o którym tutaj nie wspomniałem?

Rozwiązanie nr 1 podoba mi się bardziej, ale nie znalazłem zbyt wielu domyślnych implementacji, które zabezpieczyłyby mnie w tym, że idę w dobrym kierunku.

Mam nadzieję, że moje pytanie nie zostanie zamknięte. Naprawdę nie wiem, gdzie jeszcze o to zapytać.

Z góry dziękuję

Augustin Riedinger
źródło
1
Czy mógłbyś podać więcej szczegółów na temat tego, co próbujesz osiągnąć? Czy w pierwszym przypadku uwierzytelnianie odbywa się w Redis, czy w samych usługach? Na drugim diagramie brakuje Redisa, czy jest to zamierzone?
Plamen Petrov
Dodałem kilka informacji. Proszę, daj mi znać, że nadal jest niejasne. Dzięki!
Augustin Riedinger
Czy zastanawiałeś się nad pomysłem stworzenia mikrousługi korzystającej z protokołu OAuth, a Twojej innej usługi używającej Token?
Tiarê Balbi
Ciekawi mnie to rozwiązanie, ale nadal nie rozumiem, jak sprawdzi się w praktyce. Czy wiesz, gdzie mogłem znaleźć jakieś standardowe implementacje tego?
Augustin Riedinger
@AugustinRiedinger, dzięki za opublikowanie tego. Rozbijam też moją monolityczną aplikację internetową na mikro usługi, robiąc małe kroki. W Twoim przypadku, czy Usługi 1-n są bezstanowe lub stanowe. Jeśli są pełne, czy myślałeś o zarządzaniu sesjami w każdej z tych usług. Dzięki
Manchanda. P

Odpowiedzi:

61

W oparciu o to, co rozumiem, dobrym sposobem rozwiązania tego problemu jest użycie protokołu OAuth 2 (więcej informacji na jego temat można znaleźć na stronie http://oauth.net/2/ )

Gdy Twój użytkownik zaloguje się do Twojej aplikacji, otrzyma token i za jego pomocą będzie mógł wysłać do innych usług, aby zidentyfikować go w żądaniu.

Model OAuth 2

Przykład Chained Microservice Design Model architektury

Zasoby:

Tiarê Balbi
źródło
1
Dzięki, jest całkiem jasne. Znalazłem ten bardzo dobry artykuł rozkładający prawie to samo rozwiązanie: dejanglozic.com/2014/10/07/...
Augustin Riedinger
16
Twoja odpowiedź jest świetna, ale w jaki sposób token wygenerowany z bramy API (z jej wnętrza lub w usłudze AuthMicroService) może być obsługiwany przez losową mikrousługę, której celem nie jest uwierzytelnianie i prawdopodobnie nie ma zarządzania oauth wewnątrz jego kod biznesowy?
mfrachet
Na przykład możesz użyć Netflix Zuul, aby wysłać token otrzymany w bramie do wszystkich usług, a oni będą znać informacje o użytkowniku. docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
Tiarê Balbi
Kolejną fajną rzeczą związaną z używaniem OAuth2 między usługami jest to, że możesz mieć punkty końcowe, które rozróżniają działania uwierzytelniane przez usługę i uwierzytelniane przez użytkownika.
cmp
2
OAuth polega bardziej na przyznaniu systemowi dostępu do danych użytkownika przechowywanych w innym systemie. Wydaje mi się, że to dobry przypadek dla SAML.
Rob Grant
8

Krótka odpowiedź: użyj uwierzytelniania opartego na tokenach typu Oauth2.0, którego można używać w aplikacjach dowolnego typu, takich jak aplikacja internetowa lub aplikacja mobilna. Następnie następowałaby sekwencja czynności wykonywanych przez aplikację internetową

  1. uwierzytelnić się u dostawcy identyfikatora
  2. zachować token dostępu w pliku cookie
  3. uzyskać dostęp do stron w aplikacji internetowej
  4. zadzwoń do służb

Schemat poniżej przedstawia potrzebne komponenty. Taka architektura oddzielająca sieć i interfejs API danych zapewni dobrą skalowalność, odporność i stabilność

wprowadź opis obrazu tutaj

Sandeep Nair
źródło
Czy AWS Lambda nie staje się „zimna” i nie wymaga czasu na uruchomienie? To spowolniłoby logowanie, prawda?
tsuz
@tsuz, AWS wprowadził teraz funkcję współbieżności w lambdzie, w której można zarezerwować współbieżność. Dzięki temu możesz rozwiązać problem z zimnym startem. docs.aws.amazon.com/lambda/latest/dg/…
Sandeep Nair
Bardzo bym chciał zobaczyć tę odpowiedź wiele lat wcześniej, jest to niezwykle proste, aby zrozumieć, w jaki sposób architektura mikrousług z niezależnymi mikrousługami uwierzytelniania i autoryzacji może być zorganizowana w celu zapewnienia dostępu do innych usług
brayancastrop
@Sandeep, myślę, że masz na myśli Provisioned współbieżność i niezarezerwowaną.
Anil Kumar
0

Do implementacji tego przy użyciu OpenID Connect należy użyć wzorca bramy API. Użytkownik zostanie uwierzytelniony przez IDP i otrzyma token JWT z serwera autoryzacyjnego. Teraz system bramy API może przechowywać ten token w bazie danych Redis i ustawić plik cookie w przeglądarce. Brama API użyje pliku cookie do zweryfikowania żądania użytkownika i wyśle ​​token do mikrousług.

Brama API działa jako pojedynczy punkt wejścia dla wszystkich typów aplikacji klienckich, takich jak publiczna aplikacja kliencka skryptów java, tradycyjna aplikacja internetowa, natywna aplikacja mobilna i aplikacje klienckie innych firm w architekturze Microservice.

Więcej informacji na ten temat można znaleźć na http://proficientblog.com/microservices-security/

ManishSingh
źródło
-2

możesz użyć idenitty server 4 do celów uwierzytelniania i autoryzacji

musisz używać architektury Firewall, dzięki czemu masz większą kontrolę nad bezpieczeństwem, solidnością, skalowalnością i łatwością użytkowania

Vijay Parmar
źródło