AWS API Gateway / Cognito Userpools / Lambdas не может передать учетные данные вызывающего абонента

Я работаю над реализацией AWS API Gateway с серверной частью Lambda. Я использую интеграцию API-шлюза с пользовательскими пулами Cognito (довольно новые) вместо создания настраиваемого авторизатора с использованием Lambda (что было рекомендовано до его интеграции).

Я создал доказательство концепции (javascript), которое аутентифицирует пользователя с помощью Cognito, а затем выполняет вызов API-шлюза с этими учетными данными. Итак, в основном, завершающий вызов API-шлюза происходит с токеном JWT, который я получил от Cognito (result.idToken.jwtToken) в заголовке авторизации. Все это работает, и я могу подтвердить, что только с этим токеном вы можете получить доступ к API.

Все работает нормально, но теперь я хочу получить доступ к идентификатору Cognito в моей Lambda; например, идентификатор или имя или адрес электронной почты. Я читал, как сопоставить все параметры, но на самом деле я просто использую стандартный шаблон «Метод сквозной передачи запроса» в запросе на интеграцию. Я регистрирую все параметры в лямбде, и все параметры «когнито» пусты.

Я просмотрел много похожих вопросов, и все они предлагают включить флажок «Вызов с учетными данными вызывающего абонента» в запросе на интеграцию. В этом есть смысл.

Однако этот флажок можно установить только в том случае, если вы используете AWS_IAM в качестве авторизации, и нет, если вы выбрали свой пользовательский пул когнито. Поэтому его просто невозможно выбрать, и он фактически отключен.

Кто-нибудь знает, что делать в этом случае? Это все еще продолжается, или есть причина, по которой вы не можете включить это и получить учетные данные когнитивного анализа в своей лямбде?

Большое спасибо.


person evdh    schedule 06.09.2016    source источник
comment
Можете ли вы поделиться своим вариантом использования, в котором вам нужны учетные данные вызывающего абонента из Cognito UserPool, поскольку вы можете получить доступ к идентификатору основного пользователя в своей функции Lambda?   -  person Ka Hou Ieong    schedule 07.09.2016
comment
Конечно; нам нужно регистрировать / хранить некоторую информацию о том, какой пользователь к каким данным получил доступ (плюс некоторая дополнительная информация) для отчетности. Для этого нам нужна дополнительная информация о пользователе. Я ожидал, что это будет отправлено, потому что в шаблоне «Метод сквозной передачи запроса» некоторые поля когнито явно сопоставлены («когнито-аутентификация-провайдер», «когнито-аутентификация-тип», «когнито-идентификатор-идентификатор» , 'cognito-identity-pool-id'. Но все они становятся пустыми, когда достигается лямбда. Кроме того, я проверил идентификатор-авторизатора-принципала, который также пуст. Есть предложения?   -  person evdh    schedule 07.09.2016
comment
Вы можете получить доступ к подписке или электронной почте по $ context.authorizer.claims.sub, $ context.authorizer.claims.email   -  person Ka Hou Ieong    schedule 07.09.2016
comment
Большое спасибо! Это помогло. Я также нашел две другие статьи с тем же решением после поиска свойств, которые вы упомянули. Также предлагается настроить стандартный шаблон API Gateway 'Method Request Passthrough' таким образом, чтобы эти свойства передавались как стандартные (что является отличной идеей и сэкономит много времени). Статьи здесь: forum.aws.amazon.com/message.jspa?messageID=739295 и github.com/aws/amazon-cognito-identity -js / issues / 92. Спасибо еще раз. Если хотите, можете отправить его в качестве ответа, и я могу с этим согласиться.   -  person evdh    schedule 08.09.2016


Ответы (1)


Если вам нужно зарегистрировать информацию о пользователе в своем бэкэнде, вы можете использовать $context.authorizer.claims.sub и $context.authorizer.claims.email, чтобы получить подписку и электронную почту для вашего пула пользователей Cognito.

Вот документация по Использование Amazon Cognito Ваш пул пользователей в API Gateway

person Ka Hou Ieong    schedule 08.09.2016
comment
Я пробовал это, но на сервере получаются пустые значения: {context: {sub:, email:}} - person Tejas Sherdiwala; 26.06.2017
comment
@Ka Hou Ieong, это все еще актуальный ответ? В последние дни я нашел несколько ответов, подобных вашему, с добавленными в последние дни комментариями о том, что эти claims и $context пусты. - person nicq; 04.07.2017
comment
Умм, я не могу понять, каков эквивалент лямбда-выражения Java? (на объекте context отсутствует getAuthorizer - person Blundell; 02.12.2018
comment
В Java это будет APIGatewayProxyRequestEvent (из ввода) .getRequestContext() (ProxyRequestContext) .getAuthorizer() (Map ‹String, Object›) .get("claims") (Map ‹String, String› Я думаю) .get("sub"). Обратите внимание, что вы не получите Authorizer, если будете тестировать его через API-шлюз. - person Hammer Bro.; 05.09.2020