Чтобы правильно ответить на ваш вопрос, нам нужна дополнительная информация.
- Можно ли настроить внутренние рабочие процессы для использования служб REST?
- Какие процессы аутентификации поддерживает внутренние рабочие процессы?
SDK или нет SDK
Доступ к веб-сервисам в API Gateway можно получить через сгенерированный SDK или собственный код.Инструкции по созданию SDK из консоли API Gateway можно найти здесь .
. Чтобы вызвать веб-сервис с аутентификацией, можно выполнить четырьмя способами IAM, API Keys, Cognito, настраиваемый авторизатор.Я собираюсь упомянуть первые три.
IAM
- Шаг 1, создайте пользователя в IAM с ключом доступа и секретным ключом.
- Шаг 2, слишком настроена роль для доступа к API с помощью IAM.Перейдите к IAM , выберите роли, создайте роль и предоставьте ей доступ к функциям API-шлюза.Что будет выглядеть примерно так:
Пример политики IAM:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::account-id:user/Alice",
"account-id"
]
},
"Action": "execute-api:Invoke",
"Resource": [
"arn:aws:execute-api:region:account-id:api-id/stage/GET/pets"
]
}
]
}
назначьте эту роль пользователю, которого вы создали.Примеры политики доступны здесь. .Дополнительные параметры аутентификации, включающие локальные сертификаты и т. Д., См. здесь .
- Шаг 3, вызовите API с помощью AWS Secret и Key SDK .
Ключи API
Если вы добавите ключи в свои API-интерфейсы, мобильное приложение не будет работать, поскольку оно не имеет этих ключей.Было бы лучше развернуть другую версию ваших API, которые могли бы обернуть существующие, могли бы предоставить дополнительные функциональные возможности, специфичные для рабочего процесса.Чтобы узнать, как это сделать, перейдите по этой ссылке .
Преимущество ключей API состоит в том, что вы можете ограничивать доступ к функциям API-шлюза, удалять ключи по своему усмотрению, перерабатывать их и т. Д.
Cognito - федеративные пользователи
Ваши мобильные пользователи фактически аутентифицируются с использованием федеративных пользователей .Однако один из каналов федеративного пользователя оказывается cognito.Вы можете добавить больше, OpenAuth, Google, Facebook, SAML и т. Д., Здесь вы можете добавить тип аутентификации, используемый вашим клиентом.Затем пользователь будет использовать свое имя пользователя и пароль для аутентификации поставщика безопасности клиентов, затем эти учетные данные передаются в API через федеративных пользователей, и поэтому федеративные пользователи должны быть настроены на использование того же механизма аутентификации, что и ваш клиент.Смотрите следующее сообщение в блоге
Для этого решения у нас есть несколько вариантов.1. Передайте учетные данные пользователя в API с федеративными пользователями, это предполагает, что пользовательский интерфейс вызывает веб-сервис, но, как вы упомянули, это рабочий процесс, и я предполагаю, что пользователь не имеет прямого доступа к сервису, как это происходит с мобильным приложением.т.е. службы вызываются машиной как фоновый процесс на сервере.Что означает, что это решение не будет работать.Вариант 2. Создать нового пользователя, в cognito для клиента.Это то же самое, что доступ к услуге через мобильное приложение.Для этого нужно немного поработать над клиентом, так как вам нужно получить временные маркеры доступа.
- Шаг 1. Используйте SDK или закодируйте интерфейс API самостоятельно.
- Шаг 2. Сгенерируйте в Cognito пользователя для использования бэкэнд-системой.
- Шаг 3. Используйте пользователя cognito для получения токенов доступа
- Шаг 4. Используйте токены доступадля доступа к веб-сервису через API-шлюз.
Предлагаемое решение
Создайте вторую версию вашего API в качестве оболочки или расширения для вашего мобильного API и используйте APIКлючи как описано выше.Почему?
- Может ограничить доступ к API
- Другая версия означает, что вы можете расширить ее и добавить дополнительные функциональные возможности, специфичные для рабочего процесса
- Проще всего реализовать, как естьнет обмена ключами, такие обновления в заголовке запроса.
РЕДАКТИРОВАТЬ: Мое предложение решения 2 неверно.Документация AWS гласит после Чтобы включить методы API в план использования, необходимо настроить отдельные методы API для запроса ключа API.Для аутентификации и авторизации пользователей не используйте ключи API.Используйте роль IAM, авторизатор Lambda или пул пользователей Amazon Cognito.
AWS Также говорится, что для управляемого доступа
- доступно следующее Политики ресурсов позволяют создавать политики на основе ресурсов, чтобы разрешать или запрещать доступ к вашим API и методам с указанных исходных IP-адресов или конечных точек VPC.
- Стандартные роли AWS IAM и политики предлагают гибкие и надежные средства управления доступом, которые можно применять ко всему API или отдельным методам.
- Совместное использование ресурсов между источниками (CORS) позволяет вам контролировать реакцию API на перекрестные соединения.запросы ресурсов домена.
- Лямбда-авторизаторы - это лямбда-функции, которые управляют доступом к вашим методам API с использованием аутентификации токенов на предъявителя, а также информации, описываемой заголовками, путями, строками запросов, переменными этапа или контекстом.параметры запроса переменных.
- Amazon Cognito пулы пользователей позволяют создавать настраиваемые аутентичныеРешения и авторизация.
- Клиентские сертификаты SSL можно использовать для проверки того, что HTTP-запросы к вашей серверной системе поступают от API-шлюза.
- Планы использования позволяет вам предоставлять ключи API своим клиентам, а затем отслеживать и ограничивать использование этапов и методов API для каждого ключа API.
Не все описанные выше подходы предназначены, например, для авторизации.CORS фактически защищает пользователя от межсайтовых сценариев, и, как видно, ключи API предназначены только для планов использования.Политики ресурсов еще больше защищают API, ограничивая доступ к IP-адресам, поэтому вашими единственными опциями на самом деле являются роли IAM, как описано в варианте 1, и федеративные пользователи, как описано в варианте 3, или ваша собственная пользовательская лямбда-авторизация, если вы используете Lambda, иливаш собственный авторизатор, если вы используете что-то иное, чем лямбда, завернутый в API Gateway.