As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Usando AWS Lambda para integrar seu provedor de identidade Este tópico descreve como criar uma AWS Lambda função que se conecta ao seu provedor de identidade personalizado. Você pode usar qualquer provedor de identidade personalizado, como Okta, Secrets Manager ou um armazenamento de dados personalizado que inclua lógica de autorização e autenticação. OneLogin Para a maioria dos casos de uso, a forma recomendada de configurar um provedor de identidade personalizado é usar [Solução personalizada de provedor de identidade](custom-idp-toolkit.md) o. **nota** Antes de criar um servidor Transfer Family que usa o Lambda como provedor de identidade, você deve criar a função. Para obter um exemplo de função do Lambda, consulte [Exemplo de funções do Lambda](#lambda-auth-examples). Ou você pode implantar uma CloudFormation pilha que usa um dos[Modelos de função do Lambda](#lambda-idp-templates). Além disso, certifique-se de que sua função do Lambda use uma política baseada em recursos que confie no Transfer Family. Para visualizar um exemplo de política, consulte [Exemplo de política baseada em recursos do Lambda](#lambda-resource-policy). 1. Abra o [console do AWS Transfer Family](https://console.aws.amazon.com/transfer/). 1. Escolha **Criar servidor** para abrir a página **Criar servidor**. Em **Escolher um provedor de identidade**, escolha **Provedor de identidade personalizado**, conforme mostrado na captura de tela a seguir. ![\[A seção do console Escolher um provedor de identidade com Provedor de identidade personalizada selecionado. Também tem o valor padrão selecionado, que é que os usuários podem se autenticar usando sua senha ou chave.\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/images/custom-lambda-console.png) **nota** A escolha dos métodos de autenticação só estará disponível se você habilitar o SFTP como um dos protocolos do seu servidor Transfer Family. 1. Certifique-se de que o valor padrão, **Usar AWS Lambda para conectar seu provedor de identidade**, esteja selecionado. 1. Para a **AWS Lambda Função**, insira o nome da sua função do Lambda. 1. Preencha as caixas restantes e escolha **Criar servidor**. Para obter detalhes sobre as etapas restantes para criar um servidor, consulte [Configurando um endpoint de servidor SFTP, FTPS ou FTP](tf-server-endpoint.md). ## Exemplo de política baseada em recursos do Lambda Você deve ter uma política que faça referência ao servidor Transfer Family e ao ARNs Lambda. Por exemplo, é possível usar a política a seguir com sua função do Lambda que se conecta ao seu provedor de identidade. A política tem um JSON de escape como uma string. **** ``` "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\"}}} ]}" ``` **nota** No exemplo de política acima, substitua cada uma *user input placeholder* por suas próprias informações. ## Estrutura de mensagens de evento A estrutura da mensagem de evento do servidor SFTP enviada para a função do Lambda do autorizador para um IDP personalizado é a seguinte. ``` { "username": "value", "password": "value", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` Onde `username` e `password` são os valores das credenciais de login enviadas ao servidor. Por exemplo, insira o seguinte comando para se conectar: ``` sftp bobusa@server_hostname ``` A senha será solicitada: ``` Enter password: mysecretpassword ``` É possível verificar isso na sua função do Lambda imprimindo o evento passado de dentro da função do Lambda. A aparência deve ser semelhante ao exemplo a seguir. ``` { "username": "bobusa", "password": "mysecretpassword", "protocol": "SFTP", "serverId": "s-abcd123456", "sourceIp": "192.168.0.100" } ``` A estrutura do evento é semelhante para FTP e FTPS: a única diferença é que esses valores são usados para o parâmetro `protocol`, em vez de SFTP. ## Funções do Lambda para autenticação Para implementar diferentes estratégias de autenticação, edite a função do Lambda. Para ajudá-lo a atender às necessidades do seu aplicativo, você pode implantar uma CloudFormation pilha. Para obter mais informações sobre o Lambda, consulte [Guia do desenvolvedor do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) ou [Como criar funções do Lambda com Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html). **Topics** + [Valores do Lambda válidos](#lambda-valid-values) + [Exemplo de funções do Lambda](#lambda-auth-examples) + [Testar a configuração](#authentication-test-configuration) + [Modelos de função do Lambda](#lambda-idp-templates) ### Valores do Lambda válidos A tabela a seguir descreve os detalhes dos valores que o Transfer Family aceita para funções Lambda que são usadas para provedores de identidade personalizados. | Valor | Description | Obrigatório | | --- | --- | --- | | `Role` | Especifica o nome do recurso da Amazon (ARN) do perfil do IAM que controla o acesso dos seus usuários ao bucket do Amazon S3 ou ao sistema de arquivos do Amazon EFS. As políticas anexadas a essa função determinam o nível de acesso que você deseja fornecer aos usuários durante a transferência de arquivos para dentro e para fora de seu sistema de arquivos do Amazon S3 ou Amazon EFS. O perfil do IAM também deve conter uma relação de confiança que permite o servidor acesse os recursos quando estiver servindo as solicitações de transferência dos usuários. Para obter informações sobre como estabelecer um relacionamento de confiança, consulte [Estabelecer um relacionamento de confiança](requirements-roles.md#establish-trust-transfer). | Obrigatório | | `PosixProfile` | A identidade POSIX completa, incluindo ID de usuário (`Uid`), ID de grupo (`Gid`) e qualquer grupo secundário IDs (`SecondaryGids`), que controla o acesso dos usuários aos sistemas de arquivos do Amazon EFS. As permissões POSIX definidas em arquivos e diretórios em seu sistema de arquivos determinam o nível de acesso que os usuários obtêm ao transferir arquivos para dentro e para fora de seus sistemas de arquivos do Amazon EFS. | Necessário para armazenamento secundário do Amazon EFS | | `PublicKeys` | Uma lista de valores de chave pública SSH que são válidos para esse usuário. Uma lista vazia indica que esse não é um login válido. Não deve ser devolvido durante a autenticação por senha. | Opcional | | `Policy` | Uma política de sessão para seu usuário, para que você possa usar o mesmo perfil do IAM do entre vários usuários. Esta política delimita o acesso do usuário a partes do bucket do Amazon S3. Para obter mais informações sobre o uso de políticas de sessão com provedores de identidade personalizados, consulte os exemplos de políticas de sessão neste tópico. | Opcional | | `HomeDirectoryType` | O tipo de diretório (pasta) inicial que você deseja que o diretório inicial dos usuários seja quando eles fizerem login no servidor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/custom-lambda-idp.html) | Opcional | | `HomeDirectoryDetails` | Mapeamentos de diretórios lógicos que especificam quais caminhos e chaves do Amazon S3 devem estar visíveis para o usuário e como você deseja torná-los visíveis. Você precisa especificar o par `Entry` e `Target`, onde `Entry` mostra como o caminho se tornou visível e `Target` é o caminho real do Amazon S3 ou Amazon EFS. | Obrigatório se `HomeDirectoryType` tiver um valor de `LOGICAL` | | `HomeDirectory` | O diretório inicial de um usuário quando ele faz login no servidor usando o cliente. O formato depende do seu back-end de armazenamento: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/transfer/latest/userguide/custom-lambda-idp.html) O nome do bucket ou o ID do sistema de arquivos do Amazon EFS devem ser incluídos no caminho. A omissão dessas informações resultará em erros de “Arquivo não encontrado” durante as transferências de arquivos. | Opcional | **nota** `HomeDirectoryDetails` O é uma representação em string de um mapa JSON. Isso contrasta com `PosixProfile`, que é um objeto de mapa JSON real e `PublicKeys` que é uma matriz JSON de strings. Veja os exemplos de código para obter detalhes específicos do idioma. **HomeDirectory Requisitos de formato** Ao usar o `HomeDirectory` parâmetro, certifique-se de incluir o formato completo do caminho: **Para armazenamento no Amazon S3:** sempre inclua o nome do bucket no formato `/bucket-name/path` **Para armazenamento no Amazon EFS:** sempre inclua o ID do sistema de arquivos no formato `/fs-12345/path` Uma causa comum dos erros de “Arquivo não encontrado” é omitir o nome do bucket ou o ID do sistema de arquivos EFS do `HomeDirectory` caminho. `HomeDirectory`Definir como apenas `/` sem o identificador de armazenamento fará com que a autenticação seja bem-sucedida, mas as operações de arquivo falhem. ### Exemplo de funções do Lambda Esta seção apresenta alguns exemplos de funções do Lambda, tanto em NodeJS quanto em Python. **nota** Nesses exemplos, o usuário, a função, o perfil POSIX, a senha e os detalhes do diretório inicial são todos exemplos e devem ser substituídos pelos valores reais. ------ #### [ Logical home directory, NodeJS ] A função de exemplo do NodeJS a seguir fornece os detalhes de um usuário que tem um [diretório inicial lógico](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 ] A função de exemplo do NodeJS a seguir fornece os detalhes de um usuário que tem um diretório inicial baseado no caminho. ``` // 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 ] A função de exemplo do Python a seguir fornece os detalhes de um usuário que tem um [diretório inicial lógico](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 ] A função de exemplo do Python a seguir fornece os detalhes de um usuário que tem um diretório inicial baseado no caminho. ``` # 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 ``` ------ ### Testar a configuração Depois de criar seu provedor de identidade personalizado, você deve testar sua configuração. ------ #### [ Console ] **Para testar sua configuração usando o AWS Transfer Family console** 1. Abra o [console do AWS Transfer Family](https://console.aws.amazon.com/transfer/). 1. Na página **Servidores**, escolha seu novo servidor, escolha **Ações** e escolha **Testar**. 1. Insira o texto para **Nome de usuário** e **Senha** que você definiu ao implantar a CloudFormation pilha. Se você manteve as opções padrão, o nome de usuário é `myuser` e a senha é `MySuperSecretPassword`. 1. Escolha o **protocolo do servidor** e insira o endereço IP para o **IP de origem**, se você os definiu ao implantar a CloudFormation pilha. ------ #### [ CLI ] **Para testar sua configuração usando a AWS CLI** 1. Execute o comando [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html). Substitua cada `user input placeholder` por suas próprias informações, conforme descrito nas etapas subsequentes. ``` 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. Insira o ID do servidor. 1. Insira o nome de usuário e a senha que você definiu ao implantar a CloudFormation pilha. Se você manteve as opções padrão, o nome de usuário é `myuser` e a senha é `MySuperSecretPassword`. 1. Insira o protocolo do servidor e o endereço IP de origem, se você os tiver definido ao implantar a CloudFormation pilha. ------ Se a autenticação do usuário for bem-sucedida, o teste retornará uma resposta de HTTP `StatusCode: 200`, uma string vazia `Message: ""` (que, caso contrário, conteria um motivo para a falha) e um campo `Response`. **nota** No exemplo de resposta abaixo, o campo `Response` é um objeto JSON que foi “stringificado” (convertido em uma string JSON simples que pode ser usada dentro de um programa) e contém os detalhes das funções e permissões do usuário. ``` { "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": "" } ``` ### Modelos de função do Lambda Você pode implantar uma CloudFormation pilha que usa uma função Lambda para autenticação. Fornecemos vários modelos que autenticam e autorizam seus usuários usando credenciais de login. Você pode modificar esses modelos ou AWS Lambda códigos para personalizar ainda mais o acesso do usuário. **nota** Você pode criar um AWS Transfer Family servidor habilitado para FIPS CloudFormation especificando uma política de segurança habilitada para FIPS em seu modelo. As políticas de segurança disponíveis estão descritas em [Políticas de segurança para AWS Transfer Family servidores](security-policies.md) **Para criar uma CloudFormation pilha para usar na autenticação** 1. Abra o CloudFormation console em [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. *Siga as instruções para implantar uma CloudFormation pilha a partir de um modelo existente em [Seleção de um modelo de pilha no Guia](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) do AWS CloudFormation usuário.* 1. Use um dos modelos a seguir para criar uma função do Lambda para usar na autenticação no Transfer Family. + [Modelo de pilha clássico (Amazon Cognito)](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml) Um modelo básico para criar um AWS Lambda para uso como provedor de identidade personalizado em AWS Transfer Family. Ele se autentica no Amazon Cognito para autenticação baseada em senha, e as chaves públicas são retornadas de um bucket do Amazon S3 se a autenticação baseada em chave pública for usada. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente. + [AWS Secrets Manager modelo de pilha](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml) Um modelo básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Secrets Manager como um provedor de identidade. Ele se autentica com base em uma entrada AWS Secrets Manager do formato`aws/transfer/server-id/username`. Além disso, o segredo deve conter os pares de valores-chave de todas as propriedades do usuário retornadas ao Transfer Family. Após a implantação, é possível modificar o código da função do Lambda para fazer algo diferente. + [Modelo de pilha Okta](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml): um modelo básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Okta como um provedor de identidade personalizado. + Modelo de [pilha Okta-MFA: um modelo](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml) básico usado AWS Lambda com um AWS Transfer Family servidor para integrar o Okta, com a autenticação multifator, como um provedor de identidade personalizado. + [Modelo do Azure Active Directory](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml): os detalhes dessa pilha estão descritos na postagem do blog [Autenticando AWS Transfer Family com o Azure Active Directory e. AWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/) Depois que a pilha for implantada, você poderá ver detalhes sobre ela na guia **Saídas** no console. CloudFormation A implantação de uma dessas pilhas é a maneira mais fácil de integrar um provedor de identidade personalizado ao fluxo de trabalho do Transfer Family.