API-шлюз и ACL

Question

Я разрабатываю приложение на основе микросервиса с двумя конечными точками API, одна из которых предназначена для доступа пользователей.Пользователи, прошедшие проверку подлинности с помощью JWT, могут принадлежать к различным организациям, которые в свою очередь организованы иерархически.Каждый пользователь может иметь некоторую роль, которая определена для каждого типа организации;комбинация между организацией и ролями определяет, к какому API можно получить доступ от пользователя (метод и ресурс).В заключение, это может стать беспорядком!

Есть несколько библиотек, которые предоставляют функции ACL, но мне интересно, где их разместить: первое решение - это API-шлюз, который должен вызывать компонент для каждого запроса.

- JWT включает список идентификаторов ролей для пользователя. - Шлюз API проверяет JWT и использует идентификаторы ролей для поиска в таблице, где каждая роль имеет список разрешений (например, может POST / пользователи). - Если роль соответствует запросу.последний направляется на нужную услугу;в противном случае шлюз отвечает 403

. Другой вариант - добавить в архитектуру «сервис аутентификации».Шлюз просто перенаправляет все запросы, доставленные нужной службе, каждая служба (которая может зависеть от общей библиотеки) отправляет токен службе аутентификации и запрашивает разрешение для удовлетворения запроса.В этом случае служба аутентификации - это «правильная служба» для всех запросов в ресурсе / auth, она обеспечивает вход в систему / выход из системы, обновление токенов и регистрацию новых пользователей (например, когда вы нажимаете на ссылку, указанную при входе в почту)

Первое решение предусматривает «толстый шлюз», который имеет крошечный слой на логике, но заставляет все сервисы отвечать только на безопасные вызовы, разлагать всю логику аутентификации / orization и не добавляет зависимостей между сервисами, но

1. это правильный способ сделать это?
2. Существуют ли реализации шлюза API, которые обеспечивают, что функции
3. имеют некоторые другие преимущества / недостатки в обоих подходах, которые яне вижу

спасибо за ответы !!!

Answer 1

Я вернулся, чтобы поделиться своими мыслями о выборе, сделанном вокруг темы поста.Путь, которым я следовал, - это

Шлюз API знает о данных аутентификации, отправляемых вместе с запросами («заголовок авторизации» на практике), и выполняет проверки.JWT несут всю необходимую информацию, поэтому шлюз api может применять свои политики, которые неизвестны для нисходящих сервисов.

В моей архитектуре есть некоторый RBAC, который не может быть помещен в jwt, поэтомумы переместили логику контроля доступа на шлюз.Мы адаптировали пользовательскую библиотеку nodejs в качестве плагина, но я должен признать, что это испортило наш шлюз, и мы обнаружили, что конфигурация authz медленная и подвержена ошибкам.С этой стороны мы платим за отсутствие интеграции с основной информацией о конфигурации.было бы полезно что-то вроде

routes:
  - route1:
      path: /foos/:fooid/bar
      downstreamService: http://foo.cluster
      authz:
        readerRole:
          - GET
        writerRole:
          - POST
        all:
          - OPTIONS

Однако шлюз Api не может делать все сам по себе: необходимо связаться с тем, как я называю услуги «провайдера идентификации», те, кто инкапсулирует, дают право моделировать концепцию «потребителей»в платформу: пользователь, устройство, приложение.Наш шлюз API выполняет GET для идентификации на основе данных JWT, чтобы убедиться, что идентификация существует и все в порядке.Кроме того, генерация / обновление токенов не относится к API-шлюзу, но существует сервер аутентификации (один автономный, другой все еще встроен в монолит), который связан друг с другом.Все это создает большую нагрузку, но это может быть легко смягчено с помощью кэширования "identifites".просто знайте, чтобы сделать кэш недействительным, когда идентифицируются идентификаторы, или, по крайней мере, постарайтесь использовать как можно меньше информации, чтобы вы могли просто позаботиться об удалении идентификаторов

Следующие шаги для нас будут заключаться в том, чтобы сделать / купитьболее структурированный аутентификационный сервер, который будет интегрирован со шлюзом, но способен масштабироваться независимо, более понятен и прост в настройке, возможно, с каким-то пользовательским интерфейсом

Как нативный поклонник облака, я также смотрел на istio , который имеет, помимо прочего, функции аутентификации, но все же мне нужно понять, подходит ли мой подход, требующий возможности небольшой настройки