В настоящее время я строю систему на основе микросервисов на Java Spring Cloud. Некоторые микросервисы используют PostgreSQL, а некоторые - MongoDB. REST и JMS используются для связи. План состоит в том, чтобы использовать SSO и OAuth2 для аутентификации

Проблема, с которой я сталкиваюсь, заключается в том, что авторизация должна выполняться на уровне объекта / объекта домена. Это означает, что нужен какой-то ACL (Access Control List). Лучшая практика для такой архитектуры - избегать чего-то подобного и иметь грубую безопасность, вероятно, на уровне прикладного / сервисного уровня в каждом микросервисе, но, к сожалению, это невозможно.

Моя последняя идея - использовать Spring Security ACL и иметь таблицы ACL в общей базе данных между всеми микросервисами. Доступ к базе данных будет осуществляться только через инфраструктуру Spring или через API Spring. Схема БД выглядит стабильно и вряд ли изменится. В этом случае я бы просто нарушил правило о совместном использовании БД между микросервисами.

Я рассматривал различные виды распределенных решений, но оставил их:

Один микросервис с ACL и доступом к нему с помощью rest - проблема в слишком большом количестве http-вызовов и снижении производительности. Я должен был бы расширить Spring Security ACL, чтобы заменить доступ к БД остальными вызовамиACL в каждом микросервисе для своих собственных объектов - звучит вполне разумно, но представьте себе случай, когда некоторые модели чтения сущностей синхронизированы с некоторыми другими микросервисами или одним и тем же объектом, который существует в разных ограниченных контекстах (разных микросервисах). ACL могут стать действительно неуправляемыми и могут быть источником ошибок.Один микросервис с таблицами ACL, которые синхронизируются с другими микросервисами в качестве модели чтения. Проблема в том, что в Spring Security ACL для MongoDB нет поддержки. Я видел некоторые нестандартные решения на GitHub и да, это выполнимо. Но ... при создании нового объекта я должен создать запись в микросервисе, который владеет ACL, а затем он асинхронно синхронизируется как модель чтения с микросервисом, владеющим объектом. Это не звучит как простое решениеВыберите некоторый контроль доступа на основе URL на API-шлюзе. Но мне нужно как-то модифицировать ACL Spring Security. Шлюз API должен был бы знать слишком много о других сервисах. Гранулярность контроля доступа связана с гранулярностью REST API. Может быть, я не могу представить себе все последствия и другие проблемы, которые принесет этот подходНаконец, решение с разделяемой базой данных, которое я упомянул, является моим любимым. На самом деле это был первый дисквалифицирован, потому что это «общая» база данных. Но после прохождения возможностей мне показалось, что это единственный, который будет работать. Есть еще несколько дополнительных сложностей на случай, если я захочу использовать какое-то кеширование, потому что потребуется распределенный кеш.

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

Большое спасибо,

Lukas