RBA C в мультитенантных микросервисах

Question

Я участвую в разработке мультитенантного облачного SaaS. Сейчас у нас около 15 микросервисов. Мы используем mon go как серверную часть с db на каждого арендатора в качестве разделения аренды. Сейчас мы пытаемся разработать rba c для всей платформы. Ниже приведены вопросы, которые у меня есть относительно того же.

1. Должен ли я иметь центральную микрослужбу authz для управления моим rba c autz? а. При этом, если служба authz выходит из строя, затрагиваются все микросервисы, и платформа становится непригодной или непригодной для использования. (Плохо) b. Сервис будет хранить роли / разрешения для всех ресурсов в микросервисах. (Хорошо) c. Для каждого запроса, который приходит в api gw post auth будет go для authz, и перед вызовом микросервиса он может быть отклонен. (Хорошо)

2. Должен ли я иметь боковой автомобиль для каждого микрослужба как мой autz Нет единой точки отказа ... если authz не работает для какой-то службы, другая служба может продолжать работать. (хорошо) Каждая служба будет иметь свои разрешения .. (хорошо) Служба аутентификации может хранить информацию о ролях и группах для получения разрешения он должен обратиться к отдельному сервису для управления им (разрешение CRUD). (плохо) Оценка Authz происходит на индивидуальном уровне сервиса. (не уверен)

Любой другой подход?

Спасибо, Джит

Answer 1

Я хотел бы выбрать решение ниже

1. Шлюз API выполняет базовую c проверку аутентификации (действительность токена, идентификация клиента и т. Д. c, проверка идентификатора клиента и т. Д. c), если какая-либо проверка работоспособности не удалась, возвращает 401 отсюда

2. В отдельном микросервисе у нас будет промежуточное ПО, которое перехватывает запросы и проверяет правильность разрешения для ресурса. (объект), над которым выполняется операция, в случае отсутствия разрешения, пусть микросервис вернет отсюда 403.