Подход к авторизации в микросервисной архитектуре - PullRequest
1 голос
/ 28 мая 2020

Я ищу решение проблемы авторизации в среде микросервисов. У меня есть служба шлюза и 14 базовых микросервисов. Я использую IdentityServer4 для аутентификации и авторизации ресурсов. Затем я использую авторизацию на основе политик в каждой отдельной службе. Это отлично работает для большинства сценариев ios, но ...

Все микросервисы потребуют проверки сложных правил авторизации для определенных запросов. Представьте, что Facebook проверяет, являетесь ли вы и владелец ресурса связью. Эта информация может быть предоставлена ​​"службой подключения". Я размышляю, как лучше решить эту проблему, думая:

1: сделайте это один раз на уровне шлюза. Пусть шлюз вызывает «службу подключения» и заставляет все службы предполагать, что запрос авторизован для этого конкретного c сценария. Это приведет к перемещению авторизации с уровня обслуживания и потеряет некоторую гибкость, но позволит избежать дублирования. Хотя не уверен, что наделить шлюз этой дополнительной ответственностью

2: поддерживать авторизацию на уровне обслуживания, позволить каждой микросервисе вызывать «службу подключения», это создаст дублирование и сделает систему немного более болтливой. Звучит не очень хорошо

3: при изменении подключения позвольте «службе подключения» разместить сообщение на топе c, на которое подписаны все другие службы, пусть службы сохранят свои собственные записи существующих подключений. Дублирование звучит здесь плохо, но преимуществом будет то, что авторизация сохраняется на уровне обслуживания, а также есть преимущество в производительности - отсутствие задержки.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...