Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation AWS Lambda pour intégrer votre fournisseur d'identité Cette rubrique explique comment créer une AWS Lambda fonction qui se connecte à votre fournisseur d'identité personnalisé. Vous pouvez utiliser n'importe quel fournisseur d'identité personnalisé, tel qu'Okta, Secrets Manager OneLogin, ou un magasin de données personnalisé incluant une logique d'autorisation et d'authentification. Dans la plupart des cas d'utilisation, la méthode recommandée pour configurer un fournisseur d'identité personnalisé consiste à utiliser le[Solution de fournisseur d'identité personnalisée](custom-idp-toolkit.md). **Note** Avant de créer un serveur Transfer Family qui utilise Lambda comme fournisseur d'identité, vous devez créer la fonction. Pour obtenir un exemple de fonction Lambda, consultez [Exemples de fonctions Lambda](#lambda-auth-examples). Vous pouvez également déployer une CloudFormation pile qui utilise l'un des[Modèles de fonctions Lambda](#lambda-idp-templates). Assurez-vous également que votre fonction Lambda utilise une politique basée sur les ressources qui fait confiance à Transfer Family. Pour un exemple de politique, consultez [Politique basée sur les ressources Lambda](#lambda-resource-policy). 1. Ouvrez la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/). 1. Choisissez **Create server** pour ouvrir la page **Create server**. Pour **Choisir un fournisseur d'identité**, choisissez le **fournisseur d'identité personnalisé**, comme illustré dans la capture d'écran suivante. ![\[La section de console Choisissez un fournisseur d'identité avec le fournisseur d'identité personnalisé sélectionné. La valeur par défaut est également sélectionnée, à savoir que les utilisateurs peuvent s'authentifier à l'aide de leur mot de passe ou de leur clé.\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/images/custom-lambda-console.png) **Note** Le choix des méthodes d'authentification n'est disponible que si vous activez le protocole SFTP pour votre serveur Transfer Family. 1. Assurez-vous que la valeur par défaut, **Utiliser AWS Lambda pour connecter votre fournisseur d'identité**, est sélectionnée. 1. Pour **AWS Lambda fonction**, choisissez le nom de votre fonction Lambda. 1. Remplissez les cases restantes, puis choisissez **Create server**. Pour plus de détails sur les étapes restantes de création d'un serveur, consultez[Configuration d'un point de terminaison de serveur SFTP, FTPS ou FTP](tf-server-endpoint.md). ## Politique basée sur les ressources Lambda Vous devez disposer d'une politique qui fait référence au serveur Transfer Family et à Lambda ARNs. Par exemple, vous pouvez utiliser la politique suivante avec votre fonction Lambda qui se connecte à votre fournisseur d'identité. La politique est ignorée au format JSON sous forme de chaîne. **** ``` "Policy": "{\"Version\":\"2012-10-17\", \"Id\":\"default\", \"Statement\":[ {\"Sid\":\"AllowTransferInvocation\", \"Effect\":\"Allow\", \"Principal\":{\"Service\":\"transfer.amazonaws.com\"}, \"Action\":\"lambda:InvokeFunction\", \"Resource\":\"arn:aws:lambda:region:123456789012:function:my-lambda-auth-function\", \"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:transfer:region:123456789012:server/server-id\"}}} ]}" ``` **Note** Dans l'exemple de politique ci-dessus, remplacez chacune *user input placeholder* par vos propres informations. ## Structure des messages d’événements La structure du message d'événement envoyé par le serveur SFTP à la fonction Lambda d'autorisation pour un IDP personnalisé est la suivante. ``` { "username": "value", "password": "value", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` Où `username` et `password` quelles sont les valeurs des informations de connexion envoyées au serveur. Par exemple, vous entrez la commande suivante pour vous connecter : ``` sftp bobusa@server_hostname ``` Vous êtes ensuite invité à saisir votre mot de passe : ``` Enter password: mysecretpassword ``` Vous pouvez le vérifier à partir de votre fonction Lambda en imprimant l'événement transmis depuis la fonction Lambda. Il doit ressembler au bloc de texte suivant. ``` { "username": "bobusa", "password": "mysecretpassword", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` La structure des événements est similaire pour le FTP et le FTPS : la seule différence est que ces valeurs sont utilisées pour le `protocol` paramètre, plutôt que SFTP. ## Fonctions Lambda pour l'authentification Pour implémenter différentes stratégies d'authentification, modifiez la fonction Lambda. Pour répondre aux besoins de votre application, vous pouvez déployer une CloudFormation pile. Pour plus d'informations sur Lambda, consultez le [guide du AWS Lambda développeur](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou la création de fonctions [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) avec Node.js. **Topics** + [Valeurs Lambda valides](#lambda-valid-values) + [Exemples de fonctions Lambda](#lambda-auth-examples) + [Tester votre configuration](#authentication-test-configuration) + [Modèles de fonctions Lambda](#lambda-idp-templates) ### Valeurs Lambda valides Le tableau suivant décrit en détail les valeurs acceptées par Transfer Family pour les fonctions Lambda utilisées par les fournisseurs d'identité personnalisés. | Value | Description | Obligatoire | | --- | --- | --- | | `Role` | Spécifie le nom de ressource Amazon (ARN) du rôle IAM qui contrôle l'accès de vos utilisateurs à votre compartiment Amazon S3 ou à votre système de fichiers Amazon EFS. Les politiques associées à ce rôle déterminent le niveau d'accès que vous souhaitez fournir à vos utilisateurs lors du transfert de fichiers vers et depuis votre système de fichiers Amazon S3 ou Amazon EFS. Le rôle IAM doit également contenir une relation d'approbation qui permet au serveur d'accéder à vos ressources lors du traitement des demandes de transfert de votre utilisateur. Pour plus de détails sur l'établissement d'une relation de confiance, voir[Étape 1 : Établir une relation d'approbation](requirements-roles.md#establish-trust-transfer). | Obligatoire | | `PosixProfile` | L'identité POSIX complète, y compris l'ID utilisateur (`Uid`), l'ID de groupe (`Gid`) et tout groupe secondaire IDs (`SecondaryGids`), qui contrôle l'accès de vos utilisateurs à vos systèmes de fichiers Amazon EFS. Les autorisations POSIX définies sur les fichiers et répertoires de votre système de fichiers déterminent le niveau d'accès accordé à vos utilisateurs lors du transfert de fichiers depuis et vers vos systèmes de fichiers Amazon EFS. | Nécessaire pour le stockage de sauvegarde Amazon EFS | | `PublicKeys` | Liste des valeurs de clé publique SSH valides pour cet utilisateur. Une liste vide indique qu'il ne s'agit pas d'un identifiant valide. Ne doit pas être renvoyé lors de l'authentification du mot de passe. | Facultatif | | `Policy` | Une politique de session pour votre utilisateur afin que vous puissiez utiliser le même rôle IAM pour plusieurs utilisateurs. Cette stratégie étend l'accès de l'utilisateur à des parties de son compartiment Amazon S3. Pour plus d'informations sur l'utilisation des politiques de session avec des fournisseurs d'identité personnalisés, consultez les exemples de politiques de session présentés dans cette rubrique. | Facultatif | | `HomeDirectoryType` | Le type de répertoire (dossier) de destination du répertoire de base de vos utilisateurs lorsqu'ils se connectent au serveur. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/custom-lambda-idp.html) | Facultatif | | `HomeDirectoryDetails` | Des mappages de répertoires logiques qui spécifient les chemins et clés Amazon S3 ou Amazon EFS qui doivent être visibles par votre utilisateur et la manière dont vous souhaitez les rendre visibles. Vous devez spécifier la `Target` paire `Entry` et, qui `Entry` indique comment le chemin est rendu visible et correspond `Target` au chemin Amazon S3 ou Amazon EFS réel. | Obligatoire s'`HomeDirectoryType`il a une valeur de `LOGICAL` | | `HomeDirectory` | Le répertoire de destination d'un utilisateur lorsqu'il se connecte au serveur à l'aide du client. Le format dépend de votre backend de stockage : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/transfer/latest/userguide/custom-lambda-idp.html) Le nom du compartiment ou l'ID du système de fichiers Amazon EFS doit être inclus dans le chemin. L'omission de ces informations entraînera des erreurs « Fichier introuvable » lors des transferts de fichiers. | Facultatif | **Note** `HomeDirectoryDetails`est une représentation sous forme de chaîne d'une carte JSON. Cela contraste avec un véritable objet de carte JSON et `PublicKeys` un tableau JSON de chaînes. `PosixProfile` Consultez les exemples de code pour les détails spécifiques au langage. **HomeDirectory Exigences relatives au format** Lorsque vous utilisez le `HomeDirectory` paramètre, assurez-vous d'inclure le format de chemin complet : **Pour le stockage Amazon S3 :** incluez toujours le nom du compartiment dans le format `/bucket-name/path` **Pour le stockage Amazon EFS :** incluez toujours l'ID du système de fichiers dans le format `/fs-12345/path` L'une des causes fréquentes des erreurs « Fichier introuvable » est l'omission du nom du compartiment ou de l'ID du système de fichiers EFS dans le `HomeDirectory` chemin. Le réglage `HomeDirectory` sur « Juste `/` sans l'identifiant de stockage » entraînera la réussite de l'authentification, mais l'échec des opérations sur les fichiers. ### Exemples de fonctions Lambda Cette section présente quelques exemples de fonctions Lambda, à la fois en NodeJS et en Python. **Note** Dans ces exemples, l'utilisateur, le rôle, le profil POSIX, le mot de passe et les détails du répertoire de base sont tous des exemples et doivent être remplacés par vos valeurs réelles. ------ #### [ Logical home directory, NodeJS ] [L'exemple de fonction NodeJS suivant fournit les informations relatives à un utilisateur disposant d'un répertoire de base logique.](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html) ``` // GetUserConfig Lambda exports.handler = (event, context, callback) => { console.log("Username:", event.username, "ServerId: ", event.serverId); var response; // Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided. if (event.serverId !== "" && event.username == 'example-user') { var homeDirectoryDetails = [ { Entry: "/", Target: "/fs-faa1a123" } ]; response = { Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank PosixProfile: {"Gid": 65534, "Uid": 65534}, // Required for EFS access, but not needed for S3 HomeDirectoryDetails: JSON.stringify(homeDirectoryDetails), HomeDirectoryType: "LOGICAL", }; // Check if password is provided if (!event.password) { // If no password provided, return the user's SSH public key response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]; // Check if password is correct } else if (event.password !== 'Password1234') { // Return HTTP status 200 but with no role in the response to indicate authentication failure response = {}; } } else { // Return HTTP status 200 but with no role in the response to indicate authentication failure response = {}; } callback(null, response); }; ``` ------ #### [ Path-based home directory, NodeJS ] L'exemple de fonction NodeJS suivant fournit les informations relatives à un utilisateur qui possède un répertoire de base basé sur un chemin. ``` // GetUserConfig Lambda exports.handler = (event, context, callback) => { console.log("Username:", event.username, "ServerId: ", event.serverId); var response; // Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided. // There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins. if (event.serverId !== "" && event.username == 'example-user') { response = { Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank Policy: '', // Optional, JSON stringified blob to further restrict this user's permissions // HomeDirectory format depends on your storage backend: // For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john') // For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john') HomeDirectory: '/my-transfer-bucket/users/example-user' // S3 example - replace with your bucket name // HomeDirectory: '/fs-faa1a123/users/example-user' // EFS example - uncomment for EFS }; // Check if password is provided if (!event.password) { // If no password provided, return the user's SSH public key response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]; // Check if password is correct } else if (event.password !== 'Password1234') { // Return HTTP status 200 but with no role in the response to indicate authentication failure response = {}; } } else { // Return HTTP status 200 but with no role in the response to indicate authentication failure response = {}; } callback(null, response); }; ``` ------ #### [ Logical home directory, Python ] L'exemple de fonction Python suivant fournit les informations relatives à un utilisateur disposant d'un [répertoire de base logique](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html). ``` # GetUserConfig Python Lambda with LOGICAL HomeDirectoryDetails import json def lambda_handler(event, context): print("Username: {}, ServerId: {}".format(event['username'], event['serverId'])) response = {} # Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided. if event['serverId'] != '' and event['username'] == 'example-user': homeDirectoryDetails = [ { 'Entry': '/', 'Target': '/fs-faa1a123' } ] response = { 'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank 'PosixProfile': {"Gid": 65534, "Uid": 65534}, # Required for EFS access, but not needed for S3 'HomeDirectoryDetails': json.dumps(homeDirectoryDetails), 'HomeDirectoryType': "LOGICAL" } # Check if password is provided if event.get('password', '') == '': # If no password provided, return the user's SSH public key response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ] # Check if password is correct elif event['password'] != 'Password1234': # Return HTTP status 200 but with no role in the response to indicate authentication failure response = {} else: # Return HTTP status 200 but with no role in the response to indicate authentication failure response = {} return response ``` ------ #### [ Path-based home directory, Python ] L'exemple de fonction Python suivant fournit les informations relatives à un utilisateur qui possède un répertoire de base basé sur un chemin. ``` # GetUserConfig Python Lambda with PATH HomeDirectory def lambda_handler(event, context): print("Username: {}, ServerId: {}".format(event['username'], event['serverId'])) response = {} # Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided. # There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins. if event['serverId'] != '' and event['username'] == 'example-user': response = { 'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank 'Policy': '', # Optional, JSON stringified blob to further restrict this user's permissions # HomeDirectory format depends on your storage backend: # For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john') # For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john') 'HomeDirectory': '/my-transfer-bucket/users/example-user', # S3 example - replace with your bucket name # 'HomeDirectory': '/fs-faa1a123/users/example-user', # EFS example - uncomment for EFS 'HomeDirectoryType': "PATH" # Not strictly required, defaults to PATH } # Check if password is provided if event.get('password', '') == '': # If no password provided, return the user's SSH public key response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ] # Check if password is correct elif event['password'] != 'Password1234': # Return HTTP status 200 but with no role in the response to indicate authentication failure response = {} else: # Return HTTP status 200 but with no role in the response to indicate authentication failure response = {} return response ``` ------ ### Tester votre configuration Après avoir créé votre fournisseur d'identité personnalisé, vous devez tester votre configuration. ------ #### [ Console ] **Pour tester votre configuration à l'aide de la AWS Transfer Family console** 1. Ouvrez la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/). 1. Sur la page **Serveurs**, choisissez votre nouveau serveur, sélectionnez **Actions**, puis sélectionnez **Test**. 1. Entrez le texte du **nom d'utilisateur** et du **mot de passe** que vous avez définis lors du déploiement de la CloudFormation pile. Si vous avez conservé les options par défaut, le nom d'utilisateur est `myuser` et le mot de passe est`MySuperSecretPassword`. 1. Choisissez le **protocole du serveur** et entrez l'adresse IP de l'adresse **IP source**, si vous les avez définies lors du déploiement de la CloudFormation pile. ------ #### [ CLI ] **Pour tester votre configuration à l'aide de la AWS CLI** 1. Exécutez la commande [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html). Remplacez chacune `user input placeholder` par vos propres informations, comme décrit dans les étapes suivantes. ``` aws transfer test-identity-provider --server-id s-1234abcd5678efgh --user-name myuser --user-password MySuperSecretPassword --server-protocol FTP --source-ip 127.0.0.1 ``` 1. Entrez l'ID du serveur. 1. Entrez le nom d'utilisateur et le mot de passe que vous avez définis lors du déploiement de la CloudFormation pile. Si vous avez conservé les options par défaut, le nom d'utilisateur est `myuser` et le mot de passe est`MySuperSecretPassword`. 1. Entrez le protocole du serveur et l'adresse IP source, si vous les avez définis lors du déploiement de la CloudFormation pile. ------ Si l'authentification de l'utilisateur réussit, le test renvoie une réponse `StatusCode: 200` HTTP, une chaîne vide `Message: ""` (qui contiendrait la raison de l'échec dans le cas contraire) et un `Response` champ. **Note** Dans l'exemple de réponse ci-dessous, le `Response` champ est un objet JSON qui a été « stringifié » (converti en une chaîne JSON plate utilisable dans un programme) et contient les détails des rôles et autorisations de l'utilisateur. ``` { "Response":"{\"Policy\":\"{\\\"Version\\\":\\\"2012-10-17\\\",\\\"Statement\\\":[{\\\"Sid\\\":\\\"ReadAndListAllBuckets\\\",\\\"Effect\\\":\\\"Allow\\\",\\\"Action\\\":[\\\"s3:ListAllMybuckets\\\",\\\"s3:GetBucketLocation\\\",\\\"s3:ListBucket\\\",\\\"s3:GetObjectVersion\\\",\\\"s3:GetObjectVersion\\\"],\\\"Resource\\\":\\\"*\\\"}]}\",\"Role\":\"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\":\"/\"}", "StatusCode": 200, "Message": "" } ``` ### Modèles de fonctions Lambda Vous pouvez déployer une CloudFormation pile qui utilise une fonction Lambda pour l'authentification. Nous proposons plusieurs modèles qui authentifient et autorisent vos utilisateurs à l'aide de leurs identifiants de connexion. Vous pouvez modifier ces modèles ou ce AWS Lambda code pour personnaliser davantage l'accès des utilisateurs. **Note** Vous pouvez créer un AWS Transfer Family serveur compatible FIPS en CloudFormation spécifiant une politique de sécurité compatible FIPS dans votre modèle. Les politiques de sécurité disponibles sont décrites dans [Politiques de sécurité pour les AWS Transfer Family serveurs](security-policies.md) **Pour créer une CloudFormation pile à utiliser pour l'authentification** 1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/) 1. Suivez les instructions pour déployer une CloudFormation pile à partir d'un modèle existant dans la section [Sélection d'un modèle de pile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) dans le *guide de AWS CloudFormation l'utilisateur*. 1. Utilisez l'un des modèles suivants pour créer une fonction Lambda à utiliser pour l'authentification dans Transfer Family. + [Modèle de pile classique (Amazon Cognito)](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml) Un modèle de base pour créer un AWS Lambda à utiliser en tant que fournisseur d'identité personnalisé dans AWS Transfer Family. Il s'authentifie auprès d'Amazon Cognito pour l'authentification par mot de passe et les clés publiques sont renvoyées depuis un compartiment Amazon S3 si l'authentification par clé publique est utilisée. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent. + [AWS Secrets Manager modèle de pile](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml) Modèle de base à utiliser AWS Lambda avec un AWS Transfer Family serveur pour intégrer Secrets Manager en tant que fournisseur d'identité. Il s'authentifie par le biais d'une entrée au AWS Secrets Manager format`aws/transfer/server-id/username`. En outre, le secret doit contenir les paires clé-valeur pour toutes les propriétés utilisateur renvoyées à Transfer Family. Après le déploiement, vous pouvez modifier le code de la fonction Lambda pour faire quelque chose de différent. + Modèle de [pile Okta : modèle](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml) de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Okta en tant que fournisseur d'identité personnalisé. + Modèle de [pile Okta-MFA : modèle](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml) de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Okta, avec authentification multifactorielle, en tant que fournisseur d'identité personnalisé. + [Modèle Azure Active Directory](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml) : les détails de cette pile sont décrits dans le billet de blog [Authentication to AWS Transfer Family with Azure Active Directory et AWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/). Une fois la pile déployée, vous pouvez consulter les détails la concernant dans l'onglet **Sorties** de la CloudFormation console. Le déploiement de l'une de ces piles est le moyen le plus simple d'intégrer un fournisseur d'identité personnalisé dans le flux de travail Transfer Family.