Коллеги, не подскажите про авторизацию и аутентификацию в микросервисном мире.

У нас сложная ролевая структура, связанная с организационной структурой, которая должна ещё автоматически обновляться. Я так понимаю, что чаще всего управление пользователями м ролями отдается на откуп какому-то готовому authentication server, который поддерживает OAuth. А что делать в случае, если не хватит интеграции например с Active directory, которую предоставляет auth server? Неужели писать свой/допиливать? В микросервисах планируется и простая ролевая модель и ещё ACL в некоторых местах. Использовать стороннюю авторизацию не планируем.

Ну если готовой нет, то в чем проблема не делать кастомную? В распределенных системах часто делают как: Клиент заправшивает у AuthServer разрешение. Например хочу поменять ЗП Васи вот мои куки. Сервер подписывает разрешение условно на 30 сек. Далее идем уже на ресурс сервер, он проверяет подпись и разрешает действие.

Не понял фразу -"в чем проблема не делать кастомную"

Вообще у спринга есть роли и ACL.

Почему бы не сделать кастомную, если готовой нет?)

Это да, безусловно. Вопрос в том, как допатчить auth server и нужно ли. Может как-то по-другому делают

Ну свой OAuth сервер реализовать правильно - задача не из тривиальных

Посмотрите в сторону keycloak. Скорее он вам подойдет.

keycloak по идее допиливается.

Да, сейчас смотрю, спасибо. А вообще правильно ли использовать роли возвращаемые в токене от auth server?

От кейса зависит. Вообще по идее auth server уже должен знать дает он разрешение на какое то действие или нет. Зачем еще раз проверять?

Замечу, что часть данных можно положить в JWT токен, а часть получить от keycloak напрямую бэкендом. Ответ будет зависеть от того, боимся ли мы раскрывать роли и хотим ли мы пожертвовать этим ради скорости.

Тогда нарушается вся суть того, что мы делает это все распределенным. Это будут обычные стейтфул сессии

Это звучит странно, он должен знать права для каждого действия? Я думал он может максимум выдать роли которые есть у пользователя

Ну в этом есть суть микросервисов. Мы делим отвественность. Auth server отвечает за выдачу разрешений на действия. Те занимается аутентификацией, авторизацией

Вот это будет тяжело. Проверка acl может быть специфична для каждого сервиса и зависеть от его домена. Такой в auth server собирать странно

Например? Посмотри keycloak там это есть.

А оно нужно вообще? Ради чего делаете?

ACL? Да, грубо говоря доступ до объекта, зависит от того, присутствует ли пользователь в группе допустимых, что может зависеть от организационной структуры в том числе

Не, я про auth server

Ну вот пример. Можно по-разному на самом деле. Создаем нового сотрудника. Получаем разрешение у auth сервера на создаение. Тк мы админы - он нам его дает. Далее делаем запрос добавления этого ресурса в auth acl с нужными разрешениями. Далее делаем запрос создания самого сотрудника в ресурс сервере.

рассматриваю общепринятый подход по поводу организации с отдельным сервисом + OAuth jwt в микросервисной архитектуре) Аутентификация то уж точно у всех сервисов будет одинаковая, дублировать в каждом микросервисе мне кажется излишне

идею понял, почитаю, что может keycloack с acl, спасибо. А что делать со своей структурой хранения текущей? Переходить и использовать keycloack например? А для динамического обновления по интеграции все на модель keycloack завязывать получается?

Просто это может быть как купить огромный бульдозер, чтобы копать грядки на участке

а как решить задачу аутентификации тогда по-другому? распределенный persistent storage сессий? В каждом микросервисе при каждом запросе аутентифицировать пользователя?

Вы хотите масштбироваться? Это можно делать в рамках монолита. keycloak особо не юзал, там можно да https://www.keycloak.org/docs/latest/authorization_services/#_service_protection_api

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

Да по сути можно банально обращаться к общему стораджу сессий

Просто мне кажется важным понимать зачем. От этого можно разные решение придумывать. Распределенные штуки обычно очень сложные, а значит дороги в разработки.

вопрос не в этом, а в том, как это лучше сделать авторизацию и аутентификацию с учетом требований и понять ограничения и что придется менять)

На самом деле без конкретного кейса и примеров тут так не посоветуешь