Skip to main content
O login único (SSO) permite que um provedor de identidade externo autentique os usuários de um workspace Lerian. O Access Manager resolve o tenant do usuário, redireciona o navegador ao provedor e troca o código de autorização do provedor por tokens de acesso da Lerian. O SSO se aplica à entrada de usuários. Aplicações de máquina a máquina continuam usando credenciais de cliente.

​
Provedores compatíveis

O Access Manager aceita um provedor de SSO ativo por tenant. Configurar outro provedor substitui a configuração atual.
Este contrato de SSO usa OAuth 2.0 e OpenID Connect. Ele não configura um provedor SAML.

​
Como funciona a entrada

  1. O Console solicita o endereço de email do usuário.
  2. O Auth resolve o tenant a partir do domínio do email usando uma tag da organização com o prefixo domain:, como domain:example.com, ou usa a organização fixa configurada por PLUGIN_AUTH_SSO_STATIC_ORGANIZATION em um deploy BYOC de tenant único. Depois, retorna o método de entrada disponível.
  3. O Console cria um desafio PKCE S256.
  4. O Auth redireciona o navegador ao provedor de identidade configurado.
  5. O provedor autentica o usuário e retorna um código de autorização à URL de callback do Console.
  6. O Console envia o código, o state e o verificador PKCE ao Auth.
  7. O Auth verifica o fluxo e a identidade de email retornada.
  8. O Auth retorna tokens de acesso da Lerian ou continua para a verificação da MFA.
O Auth verifica se o email retornado pelo provedor pertence ao mesmo tenant que iniciou o fluxo. Ele recusa a entrada quando o email está ausente ou é resolvido para outro tenant.

​
Resolução do tenant

Um deploy BYOC single-tenant pode usar uma organização fixa. Não combine SSO com organização fixa e multi-tenancy. A descoberta não revela identificadores do tenant. Um email desconhecido recebe a mesma resposta geral que um tenant sem SSO.

​
Política de entrada com senha

Um tenant pode permitir ou desabilitar a entrada com senha local pela API do Identity. O Console não expõe um controle separado para a política de senha. Quando você configura o primeiro provedor de SSO no Console, a entrada com senha continua disponível até a primeira entrada bem-sucedida com SSO. Depois, o Auth desabilita a entrada com senha local para esse tenant. As integrações pela API podem definir a política de senha explicitamente quando precisam de outra transição:
  • Desabilitar a entrada com senha logo depois que o provedor for configurado.
  • Manter a entrada com senha disponível junto com o SSO.
Teste o SSO antes de desabilitar a entrada com senha local. Um segredo do cliente, issuer, domínio ou URL de callback inválido pode impedir que todos os usuários entrem.

​
Validação da configuração

Rode a validação de preflight antes de salvar um provedor. O preflight não muda a configuração do tenant. Ele verifica:
  • os campos obrigatórios.
  • a descoberta do OpenID Connect quando o provedor usa uma URL de issuer.
  • a validação explícita dos endpoints quando a API fornece URLs de autorização, token e informações do usuário.
  • as credenciais do cliente.
  • a URL de callback.
  • os endpoints resolvidos de autorização, token e informações do usuário.
A Okta nem sempre consegue confirmar o cadastro do callback pelo preflight. Cadastre a URL de callback na Okta antes de habilitar o provedor.

​
Próximos passos

Configure o SSO no Console

Teste, salve, revise e remova o provedor do tenant.

Requisitos de deploy do SSO

Configure URLs de callback, o roteamento público do Auth e a resolução do tenant.

Autenticação multifator

Adicione uma segunda etapa de verificação depois do SSO.