Usando AWS Lambda para integrar seu provedor de identidade - AWS Transfer Family

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 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. Ou você pode implantar uma CloudFormation pilha que usa um dosModelos de função do Lambda. 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.

  1. Abra o console de AWS Transfer Family.

  2. 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.
    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.

  3. Verifique se o valor padrão, Usar AWS Lambda para conectar seu provedor de identidade, está selecionado.

  4. Para a AWS Lambda Função, insira o nome da sua função do Lambda.

  5. 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.

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:account-id:function:my-lambda-auth-function\", \"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:transfer:region:account-id: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 ou Como criar funções do Lambda com Node.js.

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.

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.

  • Se você configurá-lo como PATH, o usuário vê os caminhos absolutos do bucket do Amazon S3 ou do EFS como estão em seus clientes de protocolo de transferência de arquivos.

  • Se você configurá-lo como LOGICAL, será necessário fornecer mapeamentos no parâmetro HomeDirectoryDetails para tornar os caminhos do Amazon S3 ou do Amazon EFS visíveis para os usuários.

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:

  • Para o Amazon S3: /bucket-name/user-home-directory

    Exemplo: /amzn-s3-demo-bucket/users/john

  • Para o Amazon EFS: /fs-12345/user-home-directory

    Exemplo: /fs-faa1a123/users/john

Importante

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. HomeDirectoryDefinir 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.

// 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.

# 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 suas configurações usando o console do AWS Transfer Family
  1. Abra o console de AWS Transfer Family.

  2. Na página Servidores, escolha seu novo servidor, escolha Ações e escolha Testar.

  3. 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.

  4. 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. 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
  2. Insira o ID do servidor.

  3. 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.

  4. 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

Para criar uma CloudFormation pilha para usar na autenticação
  1. Abra o CloudFormation console em https://console.aws.amazon.com/cloudformation.

  2. 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 do AWS CloudFormation usuário.

  3. 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)

      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

      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 formatoaws/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: 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 básico que é 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: os detalhes dessa pilha estão descritos na postagem do blog Autenticando AWS Transfer Family com o Azure Active Directory e. 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.