Jhipster: правильная архитектура для аутентификации с использованием существующей базы данных

Question

В настоящее время я работаю над приложением прототипа Jhipster. Приложение представляет собой простой шлюз с микросервисом для доступа к данным.

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

Моя первая идея заключалась в использовании микросервисов для аутентификации пользователя. Этот микросервис будет работать в другой базе данных, но это создает еще одну проблему: для вызова этой службы из шлюза мне нужен токен JWT ... и это начинает выглядеть так, как будто мне нужно пройти аутентификацию для аутентификации пользователя.

Другое решение, как было сказано ранее, состояло бы в том, чтобы на моем шлюзе было два источника данных: один для аутентификации пользователя (указывающий на существующую базу данных), а другой для данных, связанных с Jhipster (аудиты и т. Д.)

Вы знаете, что было бы лучшим в этом случае? И можете ли вы указать мне в правильном направлении для этого выбора?

Answer 1

Первое решение: вы можете легко снять защитную аутентификацию конечной точки в SecurityConfioguration на своем микросервере, чтобы вам не потребовался токен для этого, тогда вам нужно будет создать маршрут Zuul на шлюзе для/api/authenticate.

Второе решение - это хорошо известный вопрос об использовании нескольких источников данных в Spring Boot, который имеет много хорошо документированных ответов.

Может быть другое решение, состоящее в использовании существующего стороннего сервера идентификации, такого как uaa или KeyCloak, если вы можете настроить их на существующую пользовательскую базу данных.

Итак, для прототипа я бы пошел со вторым решением.

Answer 2

Предлагаю переключиться на JHipster UAA, чтобы решить эту проблему, так как вы ищете Сервис-сервис authorizastion. Кроме того, у него не должно быть собственных полномочий, обслуживаемых шлюзом. Каждая отдельная конечная точка вашего микросервиса должна находиться внутри собственного микросервиса.

Чтобы подвести итог прецеденту UAA для вас, вы получаете новую услугу, которая может аутентифицировать пользователей, обмениваться именем пользователя и паролем для JWT, например, аутентификацией JWT, а также учетными данными внутреннего клиента без пользователя , Поскольку это часть весенне-облачной безопасности, работает аудит. Имейте в виду, что «аудитором» в этом случае будет услуга (или, точнее, клиент oauth2, используемый службой), а не пользователь.