Как получить идентификатор идентификатора Cognito в AWS Lambda

Как я могу получить идентификатор идентификатора пользователя (зарегистрированный AWS Cognito), который вызвал функцию AWS Lambda? Должен ли я использовать SDK для функции Lambda для получения идентификатора идентификатора?

Ответ 1

По документам похоже, что информация о провайдере идентификации будет доступна только для вызова через Mobile SDK.

Чтобы обойти это, одним из вариантов является передача идентификатора функции вручную как часть события. Предполагая, что вы делаете что-то вроде AWS.config.credentials = new AWS.CognitoIdentityCredentials(...), вы сможете получить идентификатор через AWS.config.credentials.identityId (после обновления учетных данных).

РЕДАКТИРОВАТЬ: лучший вариант для проверки идентичности - позволить Cognito/IAM обработать его и предположить, что если пользователь может успешно вызывать функцию Lambda, это означает, что ему разрешено это делать. В этом случае, чтобы управлять проверкой пользователя, посмотрите белый список.

Ответ 2

В AWS javascript SDK внутри лямбда-функции просто используйте context.identity.cognitoIdentityId Он работает для меня

Ответ 3

Если вы запустите API-шлюз, вы можете передать идентификатор cognito (а также пользовательскую информацию и другую полезную информацию) в Lambda. Это решило проблему для меня.

http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html

Ответ 4

Если кто-то еще наткнется на это, я думаю, это поможет вам много.

Обратите внимание, что это применимо только в том случае, если вы используете Cognito User Pool Authorizer. Если вы хотите использовать AWS_IAM с идентификаторами Cognito, ознакомьтесь со своим примером github https://github.com/VictorioBerra/js-cognito-auth-example (читайте ниже в области EDIT)

Если у вас включена опция "Использовать интеграцию с Lambda Proxy", тогда у вас не будет доступа к сопоставлениям шаблонов запросов. Но вы можете получить претензии в токене в своей лямбда-функции:

exports.handler = (event, context, callback) => {
    //create a response
    const response = {
      statusCode: 200,
      body: JSON.stringify({
          "user email": event.requestContext.authorizer.claims.email,
      }),
    };
    callback(null, response);    
};

EDIT - дополнительная информация для использования AWS_IAM в качестве авторизатора APIG

В принципе, вам нужно, чтобы ваш APIG был защищен с помощью AWS_IAM. И вы должны выполнить авторизацию через Cognito Federated Identity, которая вернет sessionToken пример с использованием пулов пользователей. Это то, что делает учетные данные AWS IAM временными. Теперь у вас есть все необходимое для авторизации на APIG.

Чтобы протестировать это, загрузите настольную версию postman, введите в свой URI API (возьмите это из области сцен) и затем в разделе "Авторизация" заполните 5 полей, необходимых для подписания Sig4. Вы увидите, что объект "event.identity" в вашей лямбда-функции загружен с такими свойствами, как объект user.

Если вы хотите использовать SDK с автоматической сгенерировкой APIG, он встроен с factory, который принимает accessKey, secret и token и подписывает все для вас. То же самое с aws-sdk. Вы можете инициировать учетные данные с этими тремя элементами, и он автоматически подпишет все запросы для вас с этими временными кредитами. Если вы хотите прямо направить свой API вручную с помощью window.fetch, request, curl (здесь вставьте http-клиент), вы можете рассчитать собственный Sig4 (будьте осторожны, это может быть немного сложнее или использовать для этого современную библиотеку.

Также для записи, делая мои исследования, я заметил, что если вы хотите НЕ использовать AWS_IAM в качестве авторизатора APIG, и вы хотите использовать "Cognito Identity Pool Authorizer", который является причудливым новым вариантом в выпадающем списке APIG, вы все равно может получить тонну информации о пользователе в событии лямбда, если вы просто передадите JWT, полученную от успешного Cognito popl auth, на APIG как заголовок авторизации. Внутри этого JWT есть много атрибутов, которые вы можете настроить в настройках пула.

Профессиональное мнение IMO Я считаю, что использование авторизованного авторизации AWS_IAM является предпочтительным. Таким образом, вы можете использовать столько разных IdP, сколько хотите в Cognito Identities (Facebook, Twitter, пулы и т.д.).

Ответ 5

Для Python Lambda, вызываемого через Javascript AWS SDK/Cognito/Amplify...

https://docs.aws.amazon.com/lambda/latest/dg/python-context-object.html

context.identity.cognito_identity_id

Это должно выглядеть примерно так:

{aws region}:{ GUID }

Если вы используете Identity Pool, это вернет Cognito Federated Identity, который можно использовать для точного контроля доступа. Это безопаснее, чем полагаться на полезную нагрузку Javascript, содержащую идентификатор.

Роль авторизации Cognito Identity Pool должна иметь политику Lambda: InvokeFunction, иначе пользователь не сможет вызвать функцию в первую очередь.

Редактировать: это работает при прямом вызове лямбда-функции, а не через API-шлюз.

Edit2: пользователю Cognito разрешено вызывать лямбду, поскольку он явно установлен в роли аутентификации IAM Cognito.

Ответ 6

Мое наблюдение следующее.

Если вы вызываете API-шлюз с подписанным запросом, где вы фактически предоставляете ключ доступа, secret и sessionToken, который вы можете извлечь через (JS SDK):

AWS.config.credentials = new AWS.CognitoIdentityCredentials(...)
AWS.config.credentials.get(..)

И предположил, что ваша лямбда вызывается из API-шлюза через LAMBDA_PROXY и Authorizer AWS_IAM. Доступ к пользовательским материалам в лямбде возможен только с помощью:

exports.create = function (event, context) {
   secdata = event.requestContext.identity.cognitoAuthenticationProvider;
}

Затем вы получите, помимо прочего, "sub" пользователя Cognito UserPool. Поэтому, если вы действительно хотите узнать больше о пользователе, вам, вероятно, придется снова запросить AWS через SDK-вызов.

Ответ 7

Я использовал Kotlin, и мой Lambda-обработчик был

override fun handleRequest(event: APIGatewayProxyRequestEvent, context: Context): APIGatewayProxyResponseEvent

Но у event.requestContext не было authorizer. Решением было обновить зависимость в build.gradle с С com.amazonaws:aws-lambda-java-events:2.1.0 по com.amazonaws:aws-lambda-java-events:2.2.7. После этого я получил имя пользователя следующим образом.

val claims = requestContext.authorizer["claims"] as Map<String, String>
println(claims["cognito:username"])
println(claims["email"])