#amazon-web-services #oauth-2.0 #routes #jwt #amazon-vpc
#amazon-веб-сервисы #oauth-2.0 #маршруты #jwt #amazon-vpc
Вопрос:
Я новичок в AWS и его сервисах. Чего я хочу добиться, так это многопользовательского SaaS-приложения. Как выглядит моя концепция: Я использую Cognito для аутентификации пользователей. Там все пользователи, независимо от того, к какому арендатору они принадлежат, должны использовать один интерфейс для входа в систему. Для распознавания арендатора я использую пользовательский атрибут «custom: tenant», который я получаю от JWT при успешном входе в систему. Для самого приложения я хочу использовать виртуальные машины, и для обеспечения инкапсуляции у каждого арендатора должен быть свой собственный виртуальный компьютер.
Пример:
- Пользователь A из клиента 1 входит в систему и возвращает JWT с утверждением «custom: tenant»: «1» должен быть перенаправлен на VPC 1
- Пользователь B из Tenant 2 входит в систему и возвращает JWT с утверждением «custom: tenant»: «2» должен быть перенаправлен на VPC 2
Теперь мой вопрос: как мне добиться такой маршрутизации на основе успешного входа в соответствующий VPC? Нужны ли мне дополнительные услуги для этого или где я могу найти эти настройки?
Комментарии:
1. Просто чтобы было понятно — у вас есть экземпляры EC2 (или группы автоматического масштабирования), созданные в отдельных виртуальных машинах, вам просто нужно перенаправить запросы от FE в соответствующий серверный сервер (в соответствующем VPC)?
2. Да, точно, просто маршрутизация к соответствующему vpc на основе утверждения jwt
Ответ №1:
Существует стандартный метод маршрутизации на основе содержимого для маршрутизации на основе содержимого JWT. Обычно такими вещами управляет обратный прокси-сервер или шлюз API, размещенный перед API, который запускает некоторую пользовательскую логику для чтения JWT и соответствующего маршрута. Это также не позволяет подключаться к компонентам приложения.
ПРИМЕР
Вот пример NGINX, закодированный на LUA, языке сценариев высокого уровня, для чтения JWT и извлечения утверждения. В этом примере это зона, тогда как в вашем случае это идентификатор клиента:
НЕОБХОДИМЫЕ ТРЕБОВАНИЯ
Однако не все промежуточное программное обеспечение поддерживает этот тип маршрутизации. Например, вы не сможете сделать это с помощью простого балансировщика нагрузки. Одним из вариантов может быть использование NGINX в качестве облачной службы, управляемой, хотя это будет стоить денег. Однако хороший шлюз перед API-интерфейсами является важным архитектурным компонентом, поэтому посмотрите, считает ли ваша компания, что в него стоит инвестировать.