O blog da AWS

AWS Single Sign-On (SSO), a próxima evolução

Conteúdo originalmente escrito por Steve Roberts, Senior Technical Evangelist

O gerenciamento eficiente das identidades dos usuários em larga escala requer novas soluções que conectam mútliplas fontes de identidade, utilizadas por muitas organizações. Ao longo da jornada na nuvem, nossos clientes optam por estabelecer uma única fonte de identidade (IdP) como uma estratégia de acesso para o Service Provider (seus próprios aplicativos, SaaS e AWS).

A AWS anunciou a próxima evolução do AWS Single Sign-On, permitindo que as empresas que usam o Azure AD aproveitem seu armazenamento de identidade existente com o AWS SSO e também a sincronização automática de identidades e grupos de usuários. Agora, os usuários podem entrar nas diversas contas e aplicativos que compõem seus ambientes AWS usando a identidade única do Azure AD – sem a necessidade de lembrar nomes de usuários e senhas adicionais – e usarão a experiência de entrada com a qual estão familiarizados. Além disso, os administradores também podem se concentrar no gerenciamento de uma única fonte de identidade (IdP) de usuários no Azure AD, tendo também a conveniência de configurar os acessos a todas as contas e aplicativos AWS de forma única e centralizada.

Vamos imaginar que eu sou um administrador de uma empresa que já usa o Azure AD para identidades de usuários e agora desejo gerenciar os meus objetos no ambiente AWS utilizando as identidades existentes. Não tenho interesse em duplicar manualmente meus usuários e grupos entre Azure AD & AWS Single Sign On e consequentemente manter dois provedores de identidade – então irei habilitar o sincronismo automático. Os usuários da minha organização irão logar no ambiente AWS usando a experiência que eles já estão familiarizados (Azure AD). Para maiores informações sobre habilitar o Single Sign-On para aplicações no Azure AD, clique aqui. Para saber mais sobre o gerenciamento de permissões para contas e aplicativos da AWS, consulte o Guia do usuário do AWS Single Sign-On.

Conectando o Azure AD como um provedor de identidade (IdP) para o AWS Single Sign-On

Meu primeiro passo é conectar o Azure AD com o AWS Signle Sign-On. Inicialmente, irei efetuar login no Azure Portal da minha conta e navegar até a opção “Azure Active Directory”. Ao lado esquerdo, selecionarei a opção “Enterprise Applications”:

Então, seleciono a opção “+ New Application”, e então “Non-gallery application”*:

*Esta funcionalidade requer o Azure AD Premium.

Assim que selecionar esta opção, uma nova aba irá aparecer. Nesta nova aba, adicionei o nome “AWS Single Sign-On”* para o nome da minha aplicação e então cliquei em “Add”. Após alguns segundos, minha nova aplicação será criada e serei redirecionado para as configurações da aplicação:

* Não existe a necessidade de adicionar o mesmo nome, ele pode ser aleatório.

Agora, irei definir as configurações pra habilitar o Single Sign On e trocar metadados de federação entre o Azure AD e o AWS SSO. Seleciono a opção “Single Sign-On”:

Clico então na opção “SAML”:

Nesta próxima tela, irei descer para a opção “3”, em então em download para o arquivo XML de Federation Metadata. Irei utilizar este arquivo .xml para os próximos passos:

Com o arquivo .xml de Federation Metadata em mãos, irei para o console de Single Sign-On do AWS. Seleciono então a opção “Enable AWS SSO”. Após aproximadamente 30 segundos, minha conta AWS já estará habilitada para single sign-on e então posso continuar com a configuração de confiança com o Azure AD.

Para que eu possa alterar o provedor de identidade (IdP) para o Azure AD, seleciono a opção “Settings” e então em “Identity Source”,  a opção “Change”:

Agora, primeiro irei selecionar a opção “External Identity Provider”:

Para que a relação de confiança seja efetuada com sucesso, preciso selecionar a opção de download para o AWS SSO SAML metadata – irei utilizar este arquivo no portal do Azure AD.

Tenho então dois arquivos .xml (um coletado do Azure e um coletado do AWS):

Agora, preciso adicionar o arquivo xml coletado do Azure AD no AWS SSO (farei um upload dele na opção Identity Provider metadata):

Clico em “Next: Review” e então reviso as informações de texto e confirmo a alteração de provedor de identidade:

Assim que selecionar a opção “Change Identity Source”,  o setup da parte AWS estará concluído:

Agora, de volta para o Azure AD, irei selecionar a opção “Upload metadata file” no topo da página de configuração. Desta vez, irei efetuar o upload do arquivo .xml coletado no portal AWS e salvar as configurações:

Se já possuo um usuário no AWS SSO com o username (UPN) igual ao do Azure AD, já posso efetuar o teste do setup selecionando a opção “Test this application”:

Assim que iniciar o teste, serei redirecionado para a página do IdP:

Irei selecionar a minha conta existente no AWS SSO (neste exemplo, a conta “Billy”) e então após autenticado, serei redirecionado para o service provider (AWS):

Lembrando que o usuário para o teste existia no AWS SSO com o mesmo username:

Organizações com um número relativamente pequeno de usuários podem preferir manter as contas de usuário no AWS SSO, ao invés de optar pelo provisionamento automático. No entanto, recomendamos ativar o provisionamento automático pela conveniência na gerência de objetos. Assim, novos usuários adicionados a um grupo do Azure AD obtêm acesso automaticamente, sem a necessidade de ações adicionais. Consequentemente, os usuários que forem removidos de um grupo no Azure AD perderão automaticamente o acesso às permissões associadas no AWS SSO.

Habilitando o Provisionamento Automático

Agora que confirmei que meu Azure AD está configurado e funcionando como provedor de identidade, irei habilitar o provisionamento automático para contas de usuários. Isso significa que quando novas contas forem adicionadas ao Azure AD e adicionadas à aplicação AWS Single Sign-On, assim que o usuário efetuar o primeiro login ao portal AWS, um objeto correspondente será criado automaticamente no AWS SSO. Isso significa que como administrador, não preciso fazer nenhum trabalho de gerência de objeto adicional.

Voltando para o console do AWS Single-Sign On, navego para a tab de “Settings” e então seleciono a opção “Enable Automatic Provisioning”.

Isso irá abrir uma nova página, contendo os valores para o SCIM Endpoint e o OAuth bearer access token (que está escondido por padrão, por ser um token do protocolo de autorização). Irei copiar ambos os valores para adicionar na aplicação criada no Azure AD (por questões de segurança, não compartilhe estes valores).

Voltando para a aplicação criada no Azure AD, seleciono a opção “Provisioning”:

Nesta nova janela, seleciono a opção “Automatic”. Então, preencho com as informações copiadas anteriormente no AWS SSO. Para “Tenant URL”, colo a informação de SCIM Endpoint e para “Secret Token”, colo a informação de Access Token. Irei também adicionar um email de monitoramento caso exista uma falha de comunicação entre as partes.

Assim que confirmar que a conexão está funcionando, seleciono a opção “Save”.

 

Agora, irei selecionar a opção “Mappings”, logo após a opção de enviar o email de falha. Clico na opção “ Synchronize Azure Active Directory Users to customappsso”. Então, irei remover os atributos facsimileTelephoneNumber e mobile (eles não serão utilizados) e para o atributo mailNickname, irei alterar a opção de Source Attribute para objectId:

Assim que clicar em “Save”, irei retornar à pagina anterior e habilitar o sincronismo selecionado a opção “On” em “Provisioning Status” então em “Save” novamente.

 

Este será o “Initial Sync”, logo será mais demorado quando comparado com as sincronizações subsequentes (delta sync) que ocorrem a cada 40 minutos. Para validar o progresso do sincronismo, posso acessar a opção de Synchronization Details ou até mesmo os Audit Logs. Posso também acessar a tab de usuários no AWS Single Sign-On e validar se os usuários foram criados com sucesso no painel de navegação.

Possuo os seguintes usuários no Azure AD>AWS Single Sign-On Application:

1)      Grupo de Desenvolvedores, com os membros

a. Billy e Luis

2)      Usuarios Joao, Caio e John que não fazem parte do grupo de Desenvolvedores.

Na tab de Provisioning, valido o status do provisionamento:

Confirmo no ambiente AWS que o grupo Desenvolvedores e seus respectivos usuários foram criados com sucesso:

Confirmo no ambiente AWS que todos os usuários foram criados com sucesso:

 

Configurei Single Sign-On, e agora?

O Azure AD agora será minha fonte de identidade para os meus usuários, assim como seus grupos. A sincronização periódica irá automaticamente criar usuários correspondentes no AWS Single Sign-On, para que meus usuários possam efetuar logon no AWS unicamente com as credenciais do Azure AD. Para gerenciar as permissões, preciso configurar utilizando o console do AWS Single Sign-On. O AWS Single Sign-On utiliza o conceito de conjunto de permissões. O conjunto de permissões é um conjunto de políticas definidas pelo AWS Identity and Access Management (IAM). Assim que o conjunto de permissões for definido, aplico ele para um grupo ou usuário.

Utilizando o conjunto de permissões, posso associar uma ou mais políticas de controle para meu grupo de Desenvolvedores ou até para usuários, controlando o que eles estão autorizados a fazer após o login. O login pode ser efetuado pelo AWS Console ou AWS CLI. Para mais detalhes a respeito da utilização do single sign-on no AWS CLI, clique aqui.

Neste post, demonstrei como você pode aproveitar os novos recursos do AWS Single Sign-On para vincular a identidade dos usuários do Azure AD com as contas e aplicativos para a experiência de logon único e também como utilizar o provisionamento automático de usuários para reduzir a complexidade ao gerenciar e usar identidades. Agora, os administradores podem usar uma única fonte de confiança para gerenciar seus usuários, e os usuários não precisam mais gerenciar um login ou senha adicional para acessar suas contas e aplicativos AWS.

Esta nova fucionalidade está disponível para todos os usuários em regiões suportadas do AWS Single Sign-On. Para validar a disponibilidade regional, clique aqui.

 


 

Sobre o autor

Steve Roberts

Steve Roberts, Senior Technical Evangelist, com sede em Seattle, WA, especializado em ferramentas e tecnologias .NET. A carreira de Steve como desenvolvedor de software abrange quase trinta anos, com foco na criação de ferramentas de desenvolvedor e integrações de IDE para ajudar os desenvolvedores a serem mais produtivos nos idiomas e plataformas escolhidos. Antes de ingressar na equipe de Technical Evangelist, Steve passou sete anos como engenheiro de desenvolvimento sênior, trabalhando nos SDKs e ferramentas para desenvolvedores .NET usando a plataforma AWS. Ele foi o líder de desenvolvimento do AWS Tools para PowerShell e do AWS Tools para Microsoft Visual Studio Team Services, e também trabalhou nos AWS Toolkits para Visual Studio e Visual Studio Code, além do AWS SDK for .NET.

 

Revisor técnico – Idioma local

Caio Ribeiro Cesar

Caio atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 12 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.