Как организовать юзер-сервис в виде микросервиса?

Question

[Wan-Derer]

Допустим, есть несколько (микро)сервисов, у каждого есть бэк (Java, Spring) и фронт (React, Angular etc.). Каждому надо понимать что за Вася на него зашёл и какие данные ему можно отдавать.
Поэтому есть потребность выноса логики работы с пользователями в отдельный микросервис чтобы он раздавал токены, авторизовал, следил за ролями и пр.
По отдельности эти части (front, back, security) плюс-минус понятны, по крайней мере, можно найти примеры. А вот как они должны взаимодействовать - непонятно. При этом задача-то шаблонная, наверняка есть типовой паттерн чтобы не городить велосипеды.

Подскажите что можно почитать, посмотреть на эту тему. Где найти примеры?

Comments

[Drno]

Общая бд?

[mayton2019]

Drno, общая БД - это хорошо. Но противоречит микросервисной архитектуре. Если БД является единой точкой отказа - то зачем тогда вообще распил на микро-сервисы. Тогда уже проще их делать монолитом.

[Wan-Derer]

mayton2019, Drno,

зачем тогда вообще

Например, происходит переписывание старого огромного монолита на новые технологии. Сразу это сделать нельзя (он огромный и в эксплуатации), поэтому от него отпиливаются куски и оформляются отдельными сервисами. Со временем можно будет и БД распилить.
Мне кажется, вопрос о базе не так важен в контексте вопроса. Если я правильно понимаю, сервисы вообще ничего не должны знать о пользователях. Они просто должны иметь возможность узнать что вот этого токена зовут Пётр и ему можно отдать данные по бухгалтерии, а всё остальное - ни-ни! А вот Маша имеет право знать за транспортный цех. А Иннокентий Ананьевич вообще испортился и пусть идёт логиниться заново.
На данный момент будем считать что база общая,

[Drno]

Wan-Derer, Вы все правильно понимаете. Но у бд есть режим мастер>>слейв

А насчет микросервисов - я хз зачем из везде пихают. И где надо и где ненадо. ))

[mayton2019]

Wan-Derer, хорошо я понял. У тебя стоит тег - Spring. Это очень хорошо.

В том смысле что это сужает круг поиска и говорит нам что использовать.
Нужно смотреть какие механизмы предлагает Spring и брать просто
готовые шаблоны из spring initilizer.

Тоесть - никакого волюнтаризма. Идем уже проверенным путем.

Вобщем можно посмотреть в Spring Security, Oauth2 (client/server), Azure Active Directory
Spring LDAP.

[Wan-Derer]

Drno, я ж говорю: есть старый монолит, который переписывается на новый стек путём отпиливания от него кусков. Можно, наверно наращивать новый монолит путём прикручивания к нему отпиленного от старого, но, КМК, лучше и гибче иметь набор мелких приложений, которые когда-то потом можно будет собрать вокруг нового ядра. Хотя я в курсе сложностей микросервисов: проблемы с деплоем и пр.

mayton2019, я почитаю конечно, но мне кажется, это немного не в ту сторону. Вот есть простой пример как сделать сервис с авторизацией и токенами. Но это простая демка, поэтому у автора всё вместе: бэк с секурити и фронт на шаблонизаторе. Я могу отделить фронт от бэка, но как выделить часть секурити - не понимаю.
Как я это вижу (м.б. далее ерунда, но тем не менее). Есть старое приложение, которое логинит пользователя (своими механизмами, которые мы не трогаем). В нём есть кнопка, например "Выдать что-л со склада". Ранее она вызывала окно в старом приложении, а теперь открывает браузер с моим сервисом (на кнопку можно повесить скрипт с логикой). Т.к. пользователь уже залогинен, я не хочу чтобы он логинился ещё и в моём сервисе (кои будут плодиться). Я предполагаю что кнопка вызовет сначала юзер-сервис и скажет ему: "Вот Васямба, он проверенный камрад, залогинь его, пж." Сервис такой: "Окэ, вот тебе токен". Далее открывается сервис "Склад" и такой: "А кто это к нам пришёл? А, это Василий! А какие у Васи права? А, вот такие! Ну вот тебе, Вася твой интерфейс...". Если же Вася оставит комп и уйдёт на обед, то сервис уже предложит ему залогиниться или снова зайти через старое приложение.

[mayton2019]

Wan-Derer, ну да. Идея с юзер-сервисом вполне себе здравая. Да.

Посмотри OAuth2 Authorization Server. Кажется он поддерживает технологию JWT-токенов. Это щас самый популярный протокол авторизации.

По поводу сложностей деплоя микросервисов. Да. Есть такая проблема. Но если сравнивать с монолитом то denial of service монолита более заметна для пользователей чем недоступность отдельного микро-сервиса. Ну и для микро-сервисов есть отдельная культура деплоя. CI/CD и оркестровка и всякие blue-green техники плавного деплоя.

[Drno]

Wan-Derer, да, понял что делаете, но для меня это выглядит дико.
Проще было в lxd контейнеры распихать целиком, далее залить их на 2 разных сервака и
Вынести балансировщик на nginx в отказоустойчиваю среду, в тот же готовый докер/кубер от мейла/яндекса

Answer 1

[Андрей Мывреник]

отдельный микросервис чтобы он раздавал токены, авторизовал, следил за ролями и пр.

Это работа для сервера авторизации, есть достаточно хороших готовых решений типа Keycloak которые достаточно легко интегрировать.

Взаимодействие фронт-бэк происходит так:
1. Фронт перенаправляет пользователя в Keycloak для авторизации
2. Пользователь авторизовывается
3. Keycloak возвращает пользователя обратно на фронт с токеном в JWT формате и подписью (JWS)
4. Фронт делает авторизованные запросы в бэк с помощью этого токена
5. Бэк, используя публичный ключ из Keycloak, валидирует подпись токена и убеждается, что он не просрочен
6. Базовая информация о пользователе, Scope и его Roles находятся в токене, их можно использовать для валидации доступа к эндпойнтам бэка и понимать, кто авторизован

Comments

[Wan-Derer]

Спасибо, посмотрю.
А можно ли сделать так чтобы пользователю не приходилось вводить логин-пароль при условии что он уже авторизовался на другом сервисе?
Т.е. тот другой сервис говорит: "Вот есть пользователь, он уже залогинен, дай для него токен". Далее этот другой сервис уже пинает мой бэк, передав ему пользователя вместе с токеном.

[Андрей Мывреник]

Wan-Derer, обычно такое не делают, это не типичная практика. Если у каждого сервиса свой фронт, то это по факту отдельный сайт, в котором нужно авторизоваться как ни крути. Но если сессия в Keycloak не истекла, то авторизация в другом сервисе должна пройти быстрее без ввода логина и пароля.

[Wan-Derer]

Андрей Мывреник, Пользователи авторизуются в старой системе (не WEB). Часть её функций переносится на WEB. Хочется сделать так чтобы пользователь логинился один раз - в старой системе.
Из неё можно выполнять команды ОС (например, обратиться к WEB-сервису через CURL). Хочется как-то на этом сыграть, но пока не понимаю как.

[Андрей Мывреник]

Wan-Derer, тут уже всё зависит от того, как происходит переключение между старой системой и новой. Боюсь здесь мои полномочия на этом всё :) Единственный костыль, который мне приходит в голову, это передать токен в параметрах запроса при открытии новой системы через старую.

[Wan-Derer]

Андрей Мывреник, переключение происходит так: в системе можно создать кнопку, которая запустит команду ОС. Например: "запусти браузер по такому-то URL". В результате функция, которая раньше запускалась в UI старой системы, теперь работает как WEB-сервис.
В общем, спасибо за идеи, буду думать дальше.