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 ou un magasin de données personnalisé qui inclut une logique d'autorisation et d'authentification. OneLogin
Dans la plupart des cas d'utilisation, la méthode recommandée pour configurer un fournisseur d'identité personnalisé consiste à utiliser leSolution de fournisseur d'identité personnalisée.
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. Vous pouvez également déployer une CloudFormation pile qui utilise l'un desModèles de fonctions Lambda. 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.
-
Ouvrez la console AWS Transfer Family
. -
Choisissez Créer un serveur pour ouvrir la page Créer un serveur. Pour Choisir un fournisseur d'identité, choisissez Fournisseur d'identité personnalisé, comme illustré dans la capture d'écran suivante.
Note
Le choix des méthodes d'authentification n'est disponible que si vous activez SFTP comme l'un des protocoles de votre serveur Transfer Family.
-
Assurez-vous que la valeur par défaut, Utiliser AWS Lambda pour connecter votre fournisseur d'identité, est sélectionnée.
-
Pour AWS Lambda fonction, choisissez le nom de votre fonction Lambda.
-
Remplissez les champs restants, puis choisissez Créer un serveur. Pour plus de détails sur les étapes restantes à suivre pour créer un serveur, consultezConfiguration d'un point de terminaison de serveur SFTP, FTPS ou FTP.
Politique basée sur les ressources Lambda
Vous devez disposer d'une politique qui fait référence au serveur Transfer Family et aux ARN Lambda. Par exemple, vous pouvez utiliser la politique suivante avec votre fonction Lambda qui se connecte à votre fournisseur d'identité. La politique est échappé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 des messages d'événements du serveur SFTP envoyés à la fonction Lambda de l'autorisateur 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 vérifier cela à 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 FTP et 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 vous aider à 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 ou la section Création de fonctions Lambda avec. Node.js
Rubriques
Valeurs Lambda valides
Le tableau suivant décrit en détail les valeurs que Transfer Family accepte pour les fonctions Lambda utilisées pour les fournisseurs d'identité personnalisés.
| Value | Description | Obligatoire |
|---|---|---|
|
|
Spécifie l'Amazon Resource Name (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, consultezÉtape 1 : Établir une relation d'approbation. |
Obligatoire |
|
|
L'identité POSIX complète, y compris l'ID utilisateur ( |
Requis pour le stockage de sauvegarde Amazon EFS |
|
|
Liste des valeurs de clé publique SSH valides pour cet utilisateur. Une liste vide signifie qu'il ne s'agit pas d'un identifiant valide. Ne doit pas être renvoyé lors de l'authentification du mot de passe. |
Facultatif |
|
|
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 de cette rubrique. |
Facultatif |
|
|
Le type de répertoire (dossier) de destination du répertoire de base de vos utilisateurs lorsqu'ils se connectent au serveur.
|
Facultatif |
|
|
Mappages de répertoires logiques qui spécifient quels chemins et clés Amazon S3 ou Amazon EFS doivent être visibles pour votre utilisateur et comment vous souhaitez les rendre visibles. Vous devez spécifier la |
Obligatoire si |
|
|
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 :
ImportantLe 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
HomeDirectoryDetailsest une représentation sous forme de chaîne d'une carte JSON. Cela contraste avecPosixProfile, qui est un véritable objet cartographique JSON et PublicKeys qui est un tableau JSON de chaînes. Consultez les exemples de code pour plus de détails spécifiques à la langue.
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 « / sans 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, les détails de l'utilisateur, du rôle, du profil POSIX, du mot de passe et du répertoire de base sont tous des exemples et doivent être remplacés par vos valeurs réelles.
Tester votre configuration
Après avoir créé votre fournisseur d'identité personnalisé, vous devez tester votre configuration.
Si l'authentification de l'utilisateur réussit, le test renvoie une réponse StatusCode:
200 HTTP, une chaîne vide Message: "" (qui contiendrait un motif d'é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 qui peut être utilisée dans un programme) et contient les détails des rôles et des 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 d'informations 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 FIPS-enabled AWS Transfer Family serveur CloudFormation en spécifiant une politique FIPS-enabled de sécurité dans votre modèle. Les politiques de sécurité disponibles sont décrites dans Politiques de sécurité pour AWS Transfer Family serveurs
Pour créer un CloudFormation pile à utiliser pour l'authentification
-
Ouvrez la CloudFormation console à l'adresse https://console.aws.amazon.com/cloudformation
. -
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 du Guide de AWS CloudFormation l'utilisateur.
-
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)
Modèle de base pour créer un modèle 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 effectuer quelque chose de différent.
-
AWS Secrets Manager modèle de pile
Modèle de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Secrets Manager en tant que fournisseur d'identité. Il s'authentifie par rapport à une entrée AWS Secrets Manager du format.
aws/transfer/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 effectuer quelque chose de différent.server-id/username -
Modèle de pile Okta
: modèle de base utilisé AWS Lambda avec un AWS Transfer Family serveur pour intégrer Okta en tant que fournisseur d'identité personnalisé. -
Okta-mfa modèle de pile
: modèle 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
: les détails de cette pile sont décrits dans le billet de blog Authentification AWS Transfer Family avec Azure Active Directory et 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.
-