Cada login separado é mais uma senha para redefinir e mais uma conta para encerrar quando alguém sai da empresa. O login único (SSO) SAML conecta o seu sistema de gestão de aprendizagem ao seu provedor de identidade, de modo que as pessoas entram no treinamento com a conta corporativa e o acesso segue o seu diretório. Veja como o SAML funciona, como é a configuração com o Microsoft Entra ID, o Okta ou o Google Workspace e o que conferir antes de entrar no ar.
Como funciona o login único SAML
O SAML (Security Assertion Markup Language) 2.0 é um padrão aberto para transmitir informações de login entre dois sistemas que confiam um no outro. O LMS nunca vê a senha da pessoa: ele a envia ao seu provedor de identidade, que confirma quem ela é, com a autenticação multifator que você exigir, e a devolve com uma declaração assinada.
| Termo | O que significa |
|---|---|
| Provedor de identidade (IdP) | O sistema que autentica as suas pessoas, como Entra ID, Okta ou Google Workspace. |
| Provedor de serviço (SP) | O aplicativo em que as pessoas entram: o seu LMS. |
| Asserção (assertion) | A declaração XML assinada pelo IdP: quem é a pessoa, quando ela fez login e atributos como e-mail e nome. |
| Entity ID | Um nome exclusivo para cada lado, muitas vezes com formato de URL, mas que é apenas um identificador. Precisa corresponder exatamente. |
| ACS URL | A URL do Assertion Consumer Service: o endereço do LMS que recebe a resposta do IdP. |
| Certificado de assinatura | O IdP assina com a sua chave privada; o LMS verifica com o certificado público do IdP e rejeita asserções forjadas ou alteradas. |
| Metadados | Um arquivo XML que reúne um entity ID, endpoints e certificados, pronto para importar. |
As asserções têm vida curta e indicam o seu destinatário (o entity ID do SP). O SP rejeita tudo o que estiver expirado ou destinado a outro aplicativo.
Por que o SSO vale a pena em um LMS
- Sem senhas extras. As pessoas usam a conta do dia a dia, e o seu MFA e as suas políticas de acesso cobrem o treinamento também.
- Quem entra na empresa ganha acesso rápido. Atribua o aplicativo do LMS a um grupo, e os novos colaboradores dele podem entrar já no primeiro dia.
- Quem sai perde o acesso na origem. Desative uma pessoa no seu diretório e ela não consegue iniciar uma nova sessão no LMS. O SAML controla o login, não a conta, então arquive também a conta do LMS como parte do desligamento.
Criação de contas just-in-time
Com o provisionamento just-in-time (JIT), o LMS cria uma conta na primeira vez que alguém entra, a partir dos atributos da asserção, então não há lista de usuários para importar. Coloque limites nele:
- Restrinja-o aos seus próprios domínios de e-mail, para que um aplicativo mal configurado ou uma conta de convidado não crie usuários indesejados.
- Dê às novas contas o papel de menor privilégio e conceda direitos de administrador de forma deliberada.
- Identifique as pessoas por um identificador estável, quando o seu IdP puder enviar um, porque os endereços de e-mail mudam.
Login iniciado pelo SP vs. iniciado pelo IdP
- Iniciado pelo SP: a pessoa abre o LMS, que envia uma solicitação de autenticação ao IdP, e o IdP envia a sua resposta para a ACS URL. Funciona a partir de favoritos e de links em e-mails e costuma ser considerado o fluxo mais seguro, porque a resposta atende a uma solicitação feita pelo LMS.
- Iniciado pelo IdP: a pessoa clica no ícone do aplicativo no Microsoft My Apps, no painel do Okta ou no menu de aplicativos do Google, e o IdP envia uma resposta não solicitada para a ACS URL.
Você pode oferecer os dois; teste cada um.
Configurando o SSO SAML, passo a passo
A sequência é praticamente a mesma em qualquer lugar:
- Planeje o escopo: quem usa o SSO, quais grupos recebem o aplicativo, quais domínios de e-mail são permitidos e qual atributo identifica cada pessoa.
- Crie a conexão no LMS e anote o entity ID e a ACS URL dela.
- Crie um aplicativo SAML no seu IdP com esses valores, escolha o formato do NameID e adicione os atributos de e-mail, nome e sobrenome.
- Atribua usuários ou grupos; quem não for atribuído geralmente é recusado.
- Passe ao LMS os dados do IdP: uma URL de metadados, um arquivo de metadados ou o entity ID, a URL de login e o certificado de assinatura do IdP.
- Mapeie os atributos para os nomes que o seu IdP realmente envia.
- Teste e depois ative, e avise as pessoas sobre o que está mudando.
Notas por provedor
A documentação do seu provedor traz as telas exatas. Vale saber:
- Microsoft Entra ID: use um aplicativo empresarial que não seja da galeria, e não um registro de aplicativo, que não oferece SAML. Os nomes das claims são URIs longos, então copie-os exatamente. O object ID é um bom identificador estável. Para pessoas sem caixa de e-mail, a claim de e-mail pode vir vazia; o user principal name pode ocupar o lugar dela se for um endereço real.
- Okta: crie uma integração de aplicativo SAML 2.0. Você mesmo dá nome às declarações de atributos, então elas precisam corresponder exatamente ao mapeamento do LMS, inclusive em maiúsculas e minúsculas. O ID de usuário interno do Okta serve como identificador estável.
- Google Workspace: adicione um aplicativo SAML personalizado e baixe o arquivo de metadados. O aplicativo começa desativado, então ative-o para as unidades organizacionais ou os grupos certos. Uma configuração típica identifica as pessoas pelo e-mail principal, então planeje-se para endereços renomeados e reutilizados.
Checklist de testes
Antes de entrar no ar, confira estes itens em uma janela anônima do navegador:
- Um usuário existente entra a partir do LMS e, de novo, a partir do ícone do aplicativo.
- Um novo usuário do seu domínio recebe uma conta com o papel correto.
- Alguém não atribuído ao aplicativo é recusado.
- Alguém fora dos seus domínios permitidos é recusado.
- E-mail, nome e sobrenome chegam corretamente.
- Um administrador ainda consegue entrar pelo caminho de recuperação.
Armadilhas comuns
Diferença entre relógios (clock skew)
Se os relógios do IdP e do LMS diferirem mais do que o LMS tolera, asserções corretas são rejeitadas por ainda não serem válidas ou por já terem expirado. Isso afeta principalmente servidores de identidade próprios, então mantenha os relógios deles sincronizados.
Renovação de certificado
Os certificados de assinatura do IdP expiram e, se o LMS não confiar no substituto, todos os logins falham de uma só vez. Anote a data de expiração na agenda. Se o seu LMS puder confiar em dois certificados, adicione o novo lá primeiro e só depois ative-o no IdP; caso contrário, troque os dois lados juntos em um horário tranquilo. Teste imediatamente.
Mapeamento de atributos
Os nomes dos atributos geralmente são comparados de forma exata: um LMS que espera email não aceita Email. Confira também o identificador. Um NameID transitório muda a cada sessão e um endereço de e-mail pode mudar; um NameID persistente ou um atributo de ID imutável é estável. Se as pessoas são identificadas pelo e-mail, arquive a conta de quem saiu antes de o endereço ser reatribuído.
Domínio de e-mail incompatível
Os diretórios costumam incluir pessoas cujo nome de login não é o e-mail, terceirizados em outros domínios e funcionários de empresas adquiridas que ainda usam os domínios antigos. Se o LMS limita as contas a determinados domínios, essas pessoas são recusadas. Liste todos os domínios antes de entrar no ar.
Como a Acadenix faz
O SSO SAML está no plano Gold, com guias passo a passo para Entra ID, Okta e Google Workspace.
- Teste e depois ative. Você salva os dados do seu IdP como rascunho, executa Test configuration (testar configuração) fazendo login no seu provedor e só então ativa. Uma claim de e-mail ausente é informada junto com os nomes das claims que o seu provedor de fato enviou.
- Alterações em etapas. Um novo certificado ou tenant entra como uma atualização de configuração, e a configuração atual continua funcionando até você ativá-la.
- JIT dentro dos seus domínios. Quem não tem conta recebe uma conta de aluno no primeiro login, somente se o e-mail estiver nos domínios de cadastro da sua organização, e você pode desativar isso. Quando alguém que já tem uma conta na Acadenix entra pela primeira vez pelo seu IdP, a Acadenix envia a essa pessoa um código de uso único por e-mail para confirmar o vínculo. Isso acontece uma vez por pessoa.
- Duas formas de entrar. As pessoas começam pela sua página de login, que pode levá-las direto ao seu IdP ou mostrar um botão, ou pelo ícone no My Apps, no Okta ou no Google.
- Uma conexão, uma organização. Uma conexão SAML não é repassada às organizações abaixo da que a possui, o que importa para grupos com muitas unidades.
- Um caminho de recuperação. Se o seu IdP estiver fora do ar, os administradores ainda podem entrar com um código de uso único enviado por e-mail, e isso não pode ser desativado.
Além do SAML, as pessoas podem entrar com um código enviado por e-mail ou com uma conta Google, Microsoft ou LinkedIn. Saiba mais na nossa página de segurança.
Principais pontos
- Troque os entity IDs, a ACS URL e os metadados; depois mapeie um identificador estável e um e-mail verificado.
- Limite as contas just-in-time aos seus próprios domínios e ao papel de menor privilégio.
- Teste os dois fluxos de login, as recusas e o caminho de recuperação antes de entrar no ar.
- Anote na agenda a expiração dos certificados e arquive as contas de LMS de quem sai.
Quer conectar a Acadenix ao seu provedor de identidade? Compare os planos na nossa página de preços ou fale conosco sobre a sua configuração.
