Микросервисы - Как смоделировать поток регистров с сервером авторизации и сервером ресурсов?

Question

Я использую Java и Spring Boot для реализации экосистемы Microservice.

У меня есть 3 логические границы:

• Медикаменты (Ресурсный сервер)
• Назначения (сервер ресурсов)
• Федерация удостоверений (сервер авторизации)

Информация для входа пользователя (имя пользователя, пароль, роли и т. Д.) Поступает в микросервис Identity Federation. Личная информация пользователя (имя, фамилия, адрес, контактные лица, пол и т. Д.) Поступает в микросервис Appointments.

Теперь представьте ситуацию, когда на моем Appointments Resource Server выставлен следующий ресурс:

• GET /doctors/{id} - возвращает персональную информацию о Докторе с переданным идентификатором

А на моем Identity Federation Authorization Server у меня есть следующее:

• POST /oauth/token - ресурс, который возвращает токен.

Теперь представьте, что я POST до /oauth/token на моем Сервере авторизации, и я прошел аутентификацию и получил токен.

Хорошо, теперь я могу использовать этот токен для выполнения транзакций с серверами ресурсов.

Если я отправлю GET на /doctor/1, мой токен будет проанализирован, и я смогу прочитать все его утверждения. Роли, идентификатор пользователя, имя пользователя и т. Д.

Доктор с id = 1 не должен видеть личную информацию другого Доктора (например: Доктор с id = 4).

Итак, когда запрос приходит на /doctors/1, мне нужно проверить, совпадает ли идентификатор на токене с запрашиваемым.

Весной будет что-то вроде этого:

@GetMapping("/doctors/{id}")
@PreAuthorize("#id == authentication.doctorId")
public ResponseEntity<Object> handleGetDoctorsInformations(@PathVariable("id") Long id) {
    // logic and return
}

Но для этого мне нужно синхронизировать идентификаторы на обоих микросервисах (сервер ресурсов назначений и сервер авторизации федерации удостоверений).

Я не могу использовать Natural Key, потому что у меня есть три типа пользователей (Doctor - только один из них), которые могут войти в систему, и Natural Keys различны для обоих.

Итак, id нужно где-то сгенерировать. Я не уверен, что это лучший способ.

Что обсуждали в нашей команде:

В основном:

1. Внешний интерфейс POST к серверу авторизации с полной полезной нагрузкой Doctor JSON (с личной информацией и информацией для входа в систему).
2. Сервер авторизации создает учетную запись, генерирующую свой уникальный идентификатор.
3. Сервер авторизации увеличивает полезную нагрузку JSON с созданным идентификатором, а затем публикует JSON в очереди.
4. Сервер ресурсов прослушивает очередь, получает JSON и создает Доктора рядом с ним, сохраняя личную информацию Доктора.

Это плохой способ сделать это?

Answer 1

В этом конкретном случае вам не нужно создавать очередь с дополнительной сложностью только для проверки специального разрешения (здесь, прочитайте данные других врачей) конкретного врача. Вместо этого вы можете сгенерировать токен JWT и встроить определенную привилегию, например 'READ_DOCTORS_INFO', в полезную нагрузку токена. Затем ваш сервер ресурсов, который управляет информацией врачей, может проверить предоставленный токен и разрешить конкретному пользователю в зависимости от разрешений, встроенных в токен JWT.