Integrando Amazon Managed Grafana com SSO via ADFS

Por Lucas Henrique Garcia, Arquiteto de Soluções na AWS e Hugo Chimello, arquiteto de soluções na AWS.

Para ajudar seus clientes em sua jornada de observabilidade, a AWS oferece uma gama de soluções tanto nativas como o Amazon CloudWatch — com seu robusto ecossistema de alarmes, métricas, dashboards, testes integrados e logs — como soluções open-source gerenciadas tal qual o Amazon Managed Grafana (AMG). Serviços gerenciados como o AMG oferecem vantagens operacionais significativas, já que a AWS cuida de aspectos como aplicação de patches e correções de vulnerabilidades, operação da infraestrutura, resiliência e integrações nativas com outros serviços como AWS Identity and Access Management (IAM) e Amazon Virtual Private Cloud (VPC).

Com o objetivo de auxiliar na integração do Amazon Managed Grafana (AMG) com o Active Directory Federation Services (ADFS) via Single Sign-On (SSO), este blog lista os passos necessários para configurar ambos os lados (ADFS e AMG). Embora seja comum que os usuários utilizem outros serviços de IdP, muitas empresas ainda mantêm implementações no Amazon Elastic Compute Cloud (EC2) ou On-Premises do ADFS. Outro motivo frequente é a necessidade de integrar mais de um domínio de SSO, especialmente para aqueles que utilizam a federação via IAM Identity Center, que até o momento suporta integração com uma única floresta do Active Directory. Nesse cenário, alguns clientes optam por utilizar a autenticação SSO via ADFS para determinados serviços, enquanto empregam o IAM Identity Center SSO para outras operações.

Por fim, este blog não contempla as fases de instalação do ADFS ou a criação de uma Workspaces do AMG. Embora a instalação baseada em domínios com Active Directory em servidores tradicionais (EC2 ou ambientes virtuais/físicos on-premises) seja simples, há passos adicionais caso você utilize a versão gerenciada da AWS de domínio, AWS Directory Service. Para um guia completo de como esta instalação deve ser feita, consulte este link e para maiores informações de como instalar e configurar uma Workspace do AMG consulte esta documentação.

OBS: Por motivos de segurança, as URLs usadas neste blog estão ocultas – mas destacamos onde e como configurá-las sempre que necessário.

Etapa 01 — Configurando SSO de sua Grafana Workspace

Para iniciarmos, abra sua Workspace do Grafana e na guia inicial “Authentication” selecione a opção “Security Assertion Markup Language (SAML)”:

Figura 01 – Botão de SAML Configuration

Ao acessar a opção “SAML configuration” algumas informações sobre as URLs (endpoints) que o AMG disponibiliza para integrações de SSO via SAML serão mostradas:

Figura 02 – URLs de Configuração SAML

É importante destacar as configurações adicionais de mapeamento dos atributos. Ao configurar uma federação usando o protocolo SAML, espera-se que os dois sistemas envolvidos troquem mensagens contendo informações como a conclusão do processo de login e dados relacionados. Esses dois sistemas são o IdP (Identity Provider, responsável pelas identidades e credenciais) e o SP (Service Provider, o sistema que oferece o serviço acessado com as credenciais do IdP). Portanto, a configuração é a seguinte:

IdP: Embora o Active Directory seja utilizado como diretório de credenciais, o ADFS é responsável pela formatação dessas credenciais para o protocolo SAML e, portanto, atua como o IdP neste cenário.
SP: Amazon Managed Grafana.

Essa explicação é essencial para compreender o que está sendo realizado no passo 3 da configuração SAML (conforme ilustrado abaixo). As informações trocadas entre o IdP e o SP são usadas para autorizar o usuário e conceder permissões específicas de acesso aos sistemas federados. É nesta etapa que é definido como o acesso será concedido, utilizando a configuração chamada “Assertion Attribute Role” para indicar qual atributo do usuário do Active Directory será utilizado para mapear quem terá acesso administrativo.

Os demais atributos listados em “Additional Settings – optional” são especificações adicionais que podem ser mapeadas no IdP e enviadas para o AMG, como nome do usuário (displayname), e-mail (mail) e grupos de acesso (user.group). Essas informações sobre o usuário são exibidas na guia Profile do AMG após o login ser efetuado com sucesso, conforme ilustrado abaixo:

Figura 03 – Exemplo de login no AMG

Figura 04 – Atributos para Mapping

Na próxima seção, focada no ADFS, serão abordadas outras partes fundamentais que trabalham junto das configurações acima: a configuração de Relying Part Trust, das Claims Rules e das Access Control Policies.

Etapa 02 – Configurando o ADFS

Importante: O ADFS requer um certificado SSL configurado para garantir que a página de login possa trocar mensagens SAML de forma segura. Para ambientes de teste, pode-se utilizar o Let’s Encrypt. Uma das opções disponíveis para clientes Windows é o Win-ACME, que permite utilizar métodos como DNS para a validação da requisição de certificados. Este guia assume que já existem certificados externos válidos e um ambiente ADFS previamente instalado e configurado. Para orientações adicionais sobre essas etapas, consulte os seguintes links de referência:

A – Configurando o AMG como Relying Party Trust

Para integrar o ADFS com o AMG, é necessário criar uma “Relying Party Trust”. Para esta etapa, copie o endereço de metadata apresentado na tela de Configuração SAML:

Figura 05 – Copiando a URL de MetadataEm seguida, faça login no servidor ADFS e abra a console do serviço. Navegue até a opção “Relying Party Trust”, clique com o botão direito e, na sequência, selecione “Add Relying Party Trust”:

Figura 06 – Adicionando o “Relying Party Trust”

Selecione “Claims Aware” e clique em “Start”:

Figura 07 -Criando uma regra “Claim Aware”

Na próxima tela, selecione a primeira opção (“Import Data About…”) e cole a URL que termina em /saml/metadata, a qual foi copiada da tela de configuração SAML do AMG. Em seguida, defina um nome de exibição:

Figura 08 – Configurando o Display Name da Regra

Agora, será possível determinar os critérios de acesso que a federação deve obedecer. Embora a configuração de MFA não tenha sido realizada para este ambiente de demonstração, é crucial utilizar autenticação de dois fatores em ambientes produtivos para garantir a segurança dos acessos. No exemplo a seguir, serão concedidos acessos apenas aos grupos AWS-Grafana-Admin e AWS-Grafana-Viewer, previamente criados no Active Directory:

Figura 09 – Exemplo de Control Policies – permitindo grupos do AD. Note que você pode também exigir outros recursos durante o login, como MFA.

Observação: É importante notar que, embora seja possível personalizar o nome dos grupos para refletir as configurações e políticas internas, a configuração final utiliza esses nomes para fornecer os atributos necessários para o funcionamento correto da federação. Caso sejam utilizados nomes de grupos diferentes, é necessário reconfigurar a regra Claim 04 – Group Name Regex para garantir que os filtros sejam correspondentes. As regras serão detalhadas posteriormente neste documento. Com essa configuração definida, clique em “OK” e em “Next” até concluir as etapas de criação do “Relying Party Trust”.

Para finalizar as configurações do ADFS, será necessário criar as Claim Issuance Policies. Essas regras são essenciais para que o ADFS envie os atributos necessários nos formatos corretos para que o AMG conceda o login. Para isso, clique com o botão direito na federação recém-criada e selecione a opção “Edit Claim Issuance Policy”:

Figura 10 – Editando a Relying Party Trust

B – Criando as Claim Rules

Claim Rule 01 – EmailNameId

Para criar a primeira Rule, selecione a opção “Add Rule” e em seguida utilize a opção “Send LDAP Attributs as Claims”:

Figura 11 – Criando regra de Atributos LDAP

Construa a rule com as configurações abaixo, garantindo que em “Attribute Store” a opção “Active Directory” esteja selecionada e em seguida “OK”:

Figura 12 – Regra de acesso EmailNameID

IMPORTANTE: valide sua escrita. Os objetos LDAP (coluna da esquerda) são selecionários, e podem mudar dependendo da versão do ADFS, mas as configurações da direita – com excecção de E-Mail Address que pode ser escolhido – devem ser digitados, e os nomes precisam ser exatamente como os dos atributos configurados no AMG.

Claim 02 – Claim Persistent Rule

Para adicionar a segunda regra, selecione “Add Rule” e, em seguida, escolha o tipo “Transform an Incoming Claim”.

Crie uma regra conforme a definição abaixo. Isso é necessário porque o atributo Name ID, exigido pelo AMG e por outros sistemas baseados em SAML, precisa de um mapeamento onde um valor do Active Directory (neste caso, o valor de e-mail) é convertido para o atributo denominado Name ID:

Figura 13 – Regra “Claim Persistent”

Claim 03 – Group List

Seguindo, uma nova regra deverá ser criada com o tipo “Custom Rule”:

Figura 14- Exemplo de Custom Rule

Se faz necessário escolher um nome para a regra (por exemplo, GroupList) e, em seguida, insira a configuração abaixo para permitir a validação de grupos do Active Directory via SAML:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

Figura 15 – Configuração da Regra GroupList

Claim 04 – Regex do Grupo

Semelhante à regra anterior, crie uma nova “Custom Rule”, desta vez nomeada CustomRule-GroupRegex. Esta regra tem a finalidade de enviar os dados do nome do grupo como atributo do token SAML a ser validado pelo AMG. No nosso caso, será enviado o sufixo do nome do grupo — separado pelo segundo traço — como valor.

c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"]
=> issue(Type = "user.role", Value = RegExReplace(c.Value, "AWS-Grafana-", ""));

Figura 16 – Configuração da Regra de Grupos (Regex)

Com essas regras criadas, é hora de testar o acesso via SSO.

Para iniciar o processo, acesse seu portal ADFS e faça seu login, selecionando a aplicação do Grafana. Se preferir, você também poderá abrir a página diretamente e acessar através do AMG pela opção “Sign-in with SAML”:

Figura 17 – Tela inicial de login AMG via SAML

Parabéns!

Caso as credenciais estejam corretas, será redirecionado para a console do AMG e terá acesso administrativo ao serviço para criar Dashboards:

Figura 18 – Login via SAML bem-sucedido.

Com os acessos configurados via SAML validados com sucesso, damos por encerrado este blog. A seguir, listamos algumas dicas de troubleshooting para possíveis problemas encontrados durante os testes de integração.

Apêndice

Troubleshooting:

Durante os testes de integração entre os serviços, surgiram algumas situações que necessitaram de investigações mais detalhadas. Diversos fatores podem influenciar a configuração do SSO, incluindo versões do protocolo TLS e configurações como o Device Registration (veja mais em Configuração de um servidor de federação com o Device Registration Service). Essas variáveis podem variar entre ambientes e versões de ADFS e Windows Server. Encontramos casos em que erros de Device Registration foram gerados devido à opção estar desativada (ADFS → Service → Device Registration), impedindo a criação ou atualização da Metadata do AMG. Em outras situações, a ativação do TLS 1.1 em algumas versões exigiu a desativação de suporte a essa cifra antiga. Para ajudar a resolver problemas semelhantes, aqui estão algumas sugestões de troubleshooting:

1. Habilite Logs “Verbose” para o ADFS: Verifique os logs registrados no Event Viewer (Custom Views – Server Roles – Active Directory Federation Services). Logs “Verbose” podem ser ativados com o comando PowerShell:

Set-AdfsProperties -AuditLevel Verbose

Lembre-se de retornar ao nível de log original após a análise para evitar problemas de espaço em disco e impacto na performance. O nível original pode ser restaurado com o comando:

Set-AdfsProperties -AuditLevel Basic

2. Verifique a Validade dos Certificados: Utilize o MMC do Cert Manager ou o comando Get-AdfsCertificate para garantir que seus certificados estejam válidos (dentro do período de validade e associados às funções do ADFS, como Token-Signing e Token-Decrypting). Se necessário, o comando Set-ADFSCertificate pode ser usado para reconfigurar certificados.

3. Verifique Configurações de Claim Rules: Erros não registrados no ADFS durante o login SAML via dashboard do Grafana estão frequentemente relacionados a discrepâncias nas configurações de Claim Rules em comparação com as configurações do Grafana. As configurações são sensíveis a maiúsculas e minúsculas (case sensitive), então assegure-se de que as claims estejam exatamente iguais em ambos os lados (por exemplo, user.role é diferente de user.Role). Verifique também se o atributo utilizado para login (como mail, no nosso caso) está devidamente preenchido no objeto de usuário no Active Directory.

Autor

Lucas Henrique Garcia é Arquiteto de Soluções do time de Enterprise e trabalhou previamente no time de Premium Support da AWS em Dublin. Seu foco está em ajudar clientes da AWS a resolverem seus problemas e a desenhar arquiteturas para seus negócios.

Revisor / Co-Autor

Hugo Chimello é arquiteto de soluções de para o setor telecomunicações e trabalha há 5 anos na AWS. Ele trabalha para auxiliar os clientes em suas transformações, modernizações e migrações digitais. Seu profundo conhecimento de análise de dados foi fundamental para ajudar vários clientes durante seu tempo na AWS.

Revisor

Marcelo Ferreira Baptista é Solutions Architect no time de AWS LATAM. Trabalha com soluções de TI há mais de 30 anos, com experiência em vários seguimentos de mercado e diferentes ambientes tecnológicos. Especialista em DevOps, Computing e HPC, hoje atua como Arquiteto de Soluções, apoiando os clientes nos seus desafios, buscando as melhores soluções para as suas necessidades.

O blog da AWS