Comment obtenir l'identifiant d'identité de l'utilisateur (connecté par AWS Cognito) qui a appelé une fonction AWS Lambda? Dois-je utiliser le SDK sur la fonction Lambda pour obtenir l'identifiant d'identité?
Pour les documents , il semble que les informations sur le fournisseur d'identité ne seraient disponibles que pour un appel via le kit de développement mobile.
Pour contourner ce problème, une option consiste à transmettre l'ID d'identité à la fonction manuellement dans le cadre de l'événement. En supposant que vous fassiez quelque chose comme AWS.config.credentials = new AWS.CognitoIdentityCredentials(...)
, vous devriez pouvoir obtenir l'ID via AWS.config.credentials.identityId
(après l'actualisation des informations d'identification).
EDIT: une meilleure option pour la validation de l'identité consiste à laisser Cognito/IAM la gérer et à supposer que si un utilisateur peut appeler une fonction Lambda, cela signifie qu'il est autorisé à le faire. Dans ce cas, pour gérer la validation par utilisateur, consultez liste blanche .
Dans le kit SDK javascript AWS de la fonction lambda, il suffit d'utilisercontext.identity.cognitoIdentityIdIl fonctionne pour moi
Si vous passez par API Gateway, vous pouvez transmettre l'identifiant cognito (ainsi que l'arn de l'utilisateur et d'autres informations utiles) à Lambda. Cela a résolu le problème pour moi.
http://docs.aws.Amazon.com/apigateway/latest/developerguide/api-gateway-mapping-type-reference.html
Si quelqu'un d'autre tombe sur cela, je pense que cela vous aidera beaucoup.
Notez que cela ne s'applique que si vous utilisez Cognito User Pool Authorizer. Si vous souhaitez utiliser AWS_IAM avec Cognito Identitys, consultez mon exemple github https://github.com/VictorioBerra/js-cognito-auth-example (lisez la zone EDIT ci-dessous).
Si l'option "Utiliser l'intégration du proxy Lambda" est cochée, vous n'aurez pas accès aux mappages de modèles de demande. Mais vous pouvez accéder aux revendications à l'intérieur du jeton dans votre fonction lambda:
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);
};
Fondamentalement, vous devez sécuriser votre APIG avec AWS_IAM ET vous devez vous authentifier via une identité fédérée Cognito qui renverra un sessionToken exemple utilisant des groupes d'utilisateurs . C'est ce qui rend les informations d'identification AWS IAM temporaires. Vous avez maintenant tout ce dont vous avez besoin pour authentifier votre APIG.
Pour le tester, téléchargez la version de bureau de postman , ajoutez-y votre URI d'API (récupérez-le dans la zone des étapes), puis, sous Autorisation, renseignez les 5 champs nécessaires à la signature Sig4. Vous verrez que l'objet 'event.identity' de votre fonction lambda est chargé avec des propriétés telles que l'objet user
.
Si vous souhaitez utiliser le SDK généré automatiquement par APIG, il est livré avec une usine qui prend les valeurs accessKey
, secret
et token
et qui signe tout pour vous. Même chose avec l'aws-sdk. Vous pouvez initialiser les informations d'identification avec ces trois éléments et il signera automatiquement toutes les demandes pour vous avec ces crédits temporaires. Si vous voulez frapper manuellement votre API avec window.fetch, request, curl, (insérez le client http ici), vous pouvez calculer votre propre Sig4 (attention, cela peut être un peu compliqué ou utiliser une bibliothèque moderne à faire pour vous }.
Pour mémoire, lors de mes recherches, j’ai remarqué que si vous ne souhaitez PAS utiliser AWS_IAM en tant qu’autoriseur APIG, et que vous souhaitez utiliser "Cognito Identity Pool Authorizer", une nouvelle option intéressante dans le menu déroulant d’APIG, vous pouvez toujours obtenir. une tonne d'informations sur l'utilisateur dans l'événement lambda si vous passez simplement le JWT obtenu d'une autorisation de pop-up Cognito réussie à l'APIG en tant qu'en-tête d'autorisation. JWT contient de nombreux attributs que vous pouvez personnaliser dans les paramètres de votre pool.
Avis professionnel de l’OMI Je pense qu’il est préférable d’utiliser l’autoriseur de créations temporaires AWS_IAM. De cette manière, vous pouvez utiliser autant de fournisseurs d'identité différents que vous le souhaitez dans Cognito Identities (Facebook, Twitter, pools, etc.).
Mon observation est la suivante.
Si vous appelez la passerelle API avec une demande signée dans laquelle vous fournissez les clés d'accès, secret et sessionToken que vous pouvez extraire via (JS SDK):
AWS.config.credentials = new AWS.CognitoIdentityCredentials(...)
AWS.config.credentials.get(..)
Et supposons que votre lambda soit appelé depuis API-Gateway via LAMBDA_PROXY et Authorizer AWS_IAM. Vous ne pouvez accéder aux contenus utilisateur dans lambda avec:
exports.create = function (event, context) {
secdata = event.requestContext.identity.cognitoAuthenticationProvider;
}
Ensuite, vous obtiendrez, mis à part d'autres éléments, le "sous" de l'utilisateur cognito UserPool. Donc, si vous voulez vraiment en savoir plus sur l'utilisateur, il semble que vous ayez besoin de demander à nouveau AWS via un appel SDK.