В настоящее время я создаю систему на основе микросервисов на java Spring Cloud. Некоторые микросервисы используют PostgreSQL и некоторые из них MongoDB. REST и JMS используются для связи. План заключается в использовании SSO и OAuth2 для аутентификации.Авторизация в микросервисах - как подойти к управлению доступом к объекту домена или уровня лица с помощью ACL?
Задача, с которой я сталкиваюсь, заключается в том, что авторизация должна выполняться на уровне объекта/объекта домена. Это означает, что необходим ACL (Список контроля доступа). Наилучшей практикой для такого типа архитектуры является избежание подобного рода и наличие грубой защиты на уровне приложений/уровня обслуживания в каждом микросервисе, но, к сожалению, это невозможно.
Моя последняя идея - использовать ACL Spring Security и иметь таблицы ACL в общей базе данных между всеми микросервисами. К базе данных будет обращаться только инфраструктура Spring или через Spring api. Схема БД выглядит стабильной и вряд ли изменится. В этом случае я бы просто нарушил правило о совместном использовании db между микросервисами.
Я рассматривал различные виды распределенных решений, но их оставили:
- Один microservice с ACL и доступ к нему с помощью остальное - Проблема слишком много HTTP вызовов и снижение производительности. Я должен был бы расширить Spring ACL для замены доступа к базе данных с помощью вызовов отдыха
- ACL в каждом микросервисе для своих собственных сущностей. Звучит вполне разумно, но представьте случай, когда некоторые прочитанные модели сущностей синхронизированы с некоторыми другими микросервисами или с той же сущностью, которая существует в разных ограниченных контекстах (разные микросервисы). ACL могут стать действительно неуправляемыми и могут стать источником ошибок.
- Один микросервис с таблицами ACL, которые синхронизированы с другими микросервисами в качестве модели для чтения. Проблема в том, что в Spring Security ACL для MongoDB нет поддержки. Я видел некоторые пользовательские решения на github и да, это выполнимо. Но ... при создании нового объекта мне нужно создать запись в микросервисе, который владеет ACL, а затем он асинхронно синхронизируется как модель чтения для микросервиса, владеющего объектом. Это не звучит как простое решение.
- Выберите элемент управления доступом на основе URL на шлюзе API. Но мне пришлось бы каким-то образом изменить Spring ACL. Шлюз API должен знать слишком много о других сервисах. Гранулярность контроля доступа связана с детализацией REST api. Может быть, я не могу представить все последствия и другие проблемы, которые приведут к этому подходу.
- Наконец-то решение с общим db, о котором я упоминал, является моим фаворитом. На самом деле это был первый, который я дисквалифицировал, потому что это «общая» база данных. Но, пройдя через возможности, мне показалось, что это единственная работа. Существует еще одна дополнительная сложность в случае, если я хотел бы использовать какое-то кеширование, потому что понадобится распределенный кеш.
Я бы действительно использовал некоторые советы и мнения, как подойти к архитектуре, потому что это действительно сложно, и здесь многое может пойти не так.
Большое спасибо,
Lukas
Я тоже рассматриваю этот подход. Теперь я ищу библиотеку webapp, которая предоставит графический интерфейс администратора ACL. Как вы это делаете? Все вручную вручную? – Adam
Ну, наконец, в конце концов я оставил ACL и сделал несколько простых пользовательских расширений для Spring, которые позволили мне уйти без сохранения информации о доступе к объекту. После нескольких обсуждений с владельцами продуктов мы выяснили, что есть способ решить эту проблему, используя некоторую «логику безопасности». С моей точки зрения, всегда лучше, если это возможно. Другое дело, что Spring предлагает инструменты для оценки с помощью ACL, но нет инструментов, которые помогут вам установить или обновить таблицы ACL. –