Utilizando o Azure AD como provedor de identidade para o OpenSearch Dashboards no Amazon OpenSearch Service

Por Luciano Bernardes, Arquiteto de Soluçõe Senior para Parceiros na AWS
Caio Cesar, Especialista em Microsoft na AWS
Rafael Gumiero, Arquiteto de Soluções Senior para Analytics na AWS
Robert da Costa, Arquiteto de Soluções Senior na AWS

O que vamos discutir neste blog?

Vamos tratar a integração do OpenSearch Dashboards com um provedor de identidade, utilizando o padrão SAML 2.0, demonstrando em um ambiente de laboratório. Em ambientes corporativos é comum que as empresas já tenham um provedor de identidade para centralizar autenticação e autorização de suas aplicações / provedores de serviços, visando segurança e operacionalidade.

Amazon OpenSearch Service

O Amazon OpenSearch Service facilita a execução de análises de log interativas, o monitoramento de aplicações em tempo real, pesquisas de sites e muito mais. O OpenSearch é um conjunto de pesquisa e análise de código aberto distribuído derivado do Elasticsearch. O Amazon OpenSearch Service oferece as versões mais recentes do OpenSearch, suporte para 19 versões do Elasticsearch (versões 1.5 a 7.10) e recursos de visualização fornecidos pelo OpenSearch Dashboards e Kibana (versões 1.5 a 7.10).

Identity Service Provider (IdP) & Service Provider (SP)

Um provedor de identidade (IdP) é um parceiro de federação que avalia e confirma a identidade de um usuário, podendo utilizar padrões de troca de dados, como SAML 2.0. Dessa forma o IdP autentica o usuário e fornece um token de autenticação ao provedor de serviços. No caso desse artigo, o IdP em questão é o Azure AD.

E o provedor de serviços (SP) em si é um parceiro da federação, que fornece os serviços aos usuários. O SP depende do IdP para comprovar a identidade do usuário que tenta acessar seus recursos. No caso desse artigo, o SP em questão é o OpenSearch Dashboards.

OpenSearch Dashboards & SAML 2.0

A autenticação SAML para OpenSearch Dashboards permite que você use seu provedor de identidade existente para oferecer single sign-on (SSO) em domínios do Amazon OpenSearch Service executando OpenSearch ou Elasticsearch 6.7 ou posterior. Para usar a autenticação SAML, devemos habilitar o controle de acesso refinado. Você não pode habilitar o controle de acesso refinado em domínios existentes, apenas novos. Por extensão, isso significa que você só pode habilitar a autenticação SAML em novos domínios ou domínios existentes que tenham o controle de acesso refinado já habilitado.

Requisitos

Este blog retrata as tarefas para configurar a integração do OpenSearch Dashboards com o Azure AD, portanto, os pontos abaixo já estavam provisionados em nosso lab:

- Domínio de Amazon OpenSearch Service (atentar para a nota mencionada em OpenSearch Dashboards & SAML 2.0)
- Controle de acesso refinado habilitado (Fine-grained access control – FGAC)
- Diretório de Azure Active Directory

Tarefas para realizar a integração

No domínio de Amazon OpenSearch Service ativamos o padrão SAML 2.0. No domínio já criado, fomos na aba “Security configuration” e clicamos em “Edit”:

Na área de “SAML authentication for OpenSearch Dashboards/Kibana”, marcamos a opção “Enable SAML authentication” e tomamos notas das três URLs indicadas na área “Configure identity provider (IdP)”:

No lado do Azure AD do nosso lab criamos uma enterprise application customizada. Portanto, na página do IdP clicamos em “Enterprise applications” e em seguida em “All applications \ New application”:

Na galeria com aplicações disponíveis, então clicamos em “Create your own application”:

Na lâmina aberta no lado direito, preenchemos a aplicação com um nome de fácil identificação, marcamos a opção “Integrate any other application you don’t find in the gallery (Non-gallery)” e clicamos em “Create”:

Uma vez que a aplicação foi criada, foi necessário realizar algumas configurações de permissões para usuários e/ou grupos e para que reconheça o OpenSearch Dashboards como um provedor de serviços. Sendo assim, abrimos a aplicação e fomos em “Users and groups \ Add user/group”:

Nota: Para que grupos sejam utilizados nessa integração, favor avaliar as features do Azure AD Premium.

Na tela seguinte, selecionamos usuários e grupos que deveriam ter acesso à aplicação e, consequentemente, conseguiriam fazer o Single-Sign On para o OpenSearch Dashboards. Em seguida clicamos em “Assign”:

Uma vez que o assign de usuários e/ou grupos foi realizado, conseguimos visualizar o aplicativo disponível logando com os mesmos em https://myapplications.microsoft.com:

Voltando às configurações da aplicação no Azure AD, foi necessário realizar os ajustes sobre o padrão SAML 2.0, permitindo a integração com o OpenSearch Dashboards. Sendo assim, fomos em “Single Sign-On” e clicamos em “SAML”:

Na tela seguinte, clicamos em “Edit” na seção “Basic SAML Configuration”:

Com as notas que foram tomadas no início do procedimento, disponíveis no console do Amazon OpenSearch Service, preenchemos os campos disponíveis na tela seguinte conforme abaixo e clicamos em “Save”:

Campo no Azure AD	Valor da console do Amazon OpenSearch Service
Identifier (Entity ID)	Service provider entity ID
Reply URL (Assertion Consumer Service URL)	SP-initiated SSO URL
Sign on URL	OpenSearch Dashboards URL ou Custom OpenSearch Dashboards URL

A configuração ficou semelhante à da imagem abaixo:

Na área de “Attributes & Claims”, clicamos em “Edit”, para adicionar a “group claim” necessária:

Clicamos em “Add a group claim” e lâmina de configuração aplicamos “Groups assigned to the application”, mantendo o “Source attribute” como “Group ID” e clicando em “Save”

Nota: O Azure AD envia, por padrão, somente o Object ID do grupo na requisição, conforme indicado nessa documentação.

Uma vez que essa etapa foi finalizada, baixamos o arquivo XML de Federation Metadata, para concluirmos a configuração no lado do Amazon OpenSearch Service:

No console do Amazon OpenSearch Service, fomos novamente à seção de edição dos atributos de SAML e fizemos o “Import from XML file”, apontando para o arquivo que foi baixado na etapa anterior:

Com a importação do arquivo, o campo “IdP entity ID” foi preenchido automaticamente (a formatação do XML pode variar):

Nessa mesma tela, temos duas configurações indicadas como “SAML master username” e “SAML master backend role”. Preenchemos esses campos com um usuário e um grupo do Azure AD, dando acesso master ao OpenSearch Dashboards através do Single Sign-On, sendo efetivamente administrador do serviço. Uma vez configurado pode-se utilizar desse usuário /grupo para realizar a gestão de objetos no Amazon OpenSearch Service, criando outras roles e/ou outros usuários vinculados ao Azure AD.

Nota: O “master user” tem permissões totais para administração no domínio do Amazon OpenSearch Service. Ele é o primeiro usuário a ser criado quando se cria um domínio de Amazon OpenSearch Service.

Para tal, adicionamos o valor de atributo de User Principal Name (UPN) de um usuário e o Object ID de um grupo (pode ser um ou outro) que possuem permissão na Enterprise Application do Azure Active Directory do nosso lab, conforme exemplo abaixo:

Logo abaixo, em “Additional Settings”, foi necessário preencher o atributo “Roles key – optional” com o valor “http://schemas.microsoft.com/ws/2008/06/identity/claims/groups”, que refere-se ao nome padrão do atributo de “group claims” do Azure AD, enviado na requisição:

Em caráter de teste, deixamos a Access Policy do nosso domínio Amazon OpenSearch Service como um domain level liberado para qualquer objeto autenticado.

Nota: A segurança do Amazon OpenSearch Service tem três camadas principais:

Network
A primeira camada de segurança é a rede, que determina se as solicitações podem chegar a um domínio do Amazon OpenSearch Service. Você pode escolher provisionar seu domínio de Amazon OpenSearch Service com acesso público ou somente conexões originadas a partir de uma VPC.

Domain access policy
A segunda camada de segurança é a política de acesso ao domínio. Depois que uma solicitação atinge um endpoint de domínio, a política de acesso baseada em recursos permite ou nega o acesso da solicitação a um determinado URI. A política de acesso aceita ou rejeita solicitações na “borda” do domínio, antes que elas cheguem ao próprio Amazon OpenSearch Service.

Fine-grained access control – FGAC
A terceira e última camada de segurança é o controle de acesso refinado, o FGAC. Depois que uma política de acesso baseada em recursos permite que uma solicitação chegue a um endpoint de domínio, o FGAC inicia o processo de autenticação do usuário. Se o FGCA autenticar o usuário com sucesso, ele busca todas as permissões mapeadas para esse usuário.

Finalizando essas etapas, clicamos em “Save changes” ao final da página:

Com essas configurações realizadas, utilizando o usuário e/ou membro do grupo foi possível acessar o OpenSearch Dashboards através do SSO, com a credencial de Azure AD. Para isso, o acesso pôde ser realizado através do aplicativo na página https://myapplications.microsoft.com, conforme indicado anteriormente, ou através da “OpenSearch Dashboards URL” / “Custom OpenSearch Dashboards URL” (por exemplo, https://myopensearch.mydomain.com). Nos dois cenários, o pedido de autenticação foi direcionado para o Azure AD utilizando o padrão SAML.

Com o login feito, estávamos com um usuário autorizado a realizar outras configurações pertinentes, tais como registrar novos usuários e/ou grupos do Azure AD com roles no OpenSearch Dashboards, tratando assim a autorização de acordo com a sua necessidade.

Nota: Tenants no OpenSearch Dashboards são espaços para salvar padrões de índice, visualizações, painéis e outros objetos do OpenSearch Dashboards. Por padrão, todos os usuários do OpenSearch Dashboards têm acesso a dois tenants: Privado e Global. O tenant global é compartilhado entre todos os usuários do OpenSearch Dashboards. O tenant privado é exclusivo para cada usuário e não pode ser compartilhado.

Os tenants são úteis para compartilhar seu trabalho com segurança com outros usuários do OpenSearch Dashboards. Você pode controlar quais funções têm acesso a um tenant e se essas funções têm acesso de leitura ou gravação.

Você pode usar o tenant privado para trabalhos exploratórios, criar visualizações detalhadas com sua equipe em um tenant de analistas e manter um painel de resumo para a liderança corporativa em um tenant executivo.

Pronto! Integramos o OpenSearch Dashboards com o provedor de identidade do Azure Active Directory.

Para gerenciar os objetos, bastou acessar o menu Security \ Roles:

Criamos uma nova role:

Após a criação, selecionamos a tab “Mapped users”, opção “Map users”:

Adicionamos o UPN do usuário em Users (e / ou o object ID do grupo em “Backend roles”):

Efetuando o login com o novo usuário adicionado:

Neste blog post, discutimos sobre a integração do OpenSearch Dashboards com o Azure AD através do padrão SAML 2.0, evidenciando uma alternativa para corporações manterem o controle de credenciais desse serviço através do seu IdP de escolha.

Referências

Sobre os autores

Luciano Bernardes trabalha atualmente como Sr Partner Solutions Architect (PSA) na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como PSA, trabalha próximo a parceiros de consultoria em LATAM, para apoiá-los em capacitação e escala das tecnologias da Microsoft na nuvem AWS.

Caio Ribeiro César atualmente trabalha como especialista de vendas especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 15 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.

Robert Costa é Arquiteto de Soluções Sênior que trabalha há mais de 20 anos na área de tecnologia em empresas do setor financeiro, tendo participado de diversos projetos de modernização. Hoje está dedicado a aprimorar os clientes que buscam inovação pelo uso de serviços na nuvem da AWS. Também adora viajar com a família e amigos para curtir o tempo livre à beira do mar.

Rafael Gumiero é Arquiteto de Soluções Analytics Sênior na Amazon Web Services. Entusiasta em Opensource e sistemas distribuídos, fornece orientações aos clientes que desenvolvem suas soluções com serviços Analytics AWS, ajudando-os a otimizar o valor de suas soluções.

O blog da AWS