Login único

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. Enquanto o login com passkey está ativado, o Access Manager recusa configurar um provedor de SSO.

​

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 endereço de email, como descrito em Resolução do tenant. 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, continua para a verificação da MFA ou responde AUT-0019 quando o usuário não tem nenhum método de MFA e a organização exige um.

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

---

Cada tenant é uma organização do Caradhras. O SSO usa dois campos dessa organização:

• domain é o domínio de email dos usuários do tenant, como example.com. O Auth recusa a entrada por SSO quando o domínio do email do usuário é diferente do domain do tenant.
• domainHome marca a única organização em que as pessoas desse domínio recebem a conta quando entram por SSO pela primeira vez. Cada domínio tem no máximo uma organização principal.

Uma pessoa com contas em vários tenants entra no tenant padrão dela. Se a pessoa não tiver um tenant padrão, o Auth escolhe um. No Lerian Cloud, a Lerian define esses campos para você. Em um deploy BYOC, defina-os como descrito em Requisitos de deploy do SSO. Um deploy BYOC pode usar uma organização fixa, definida com PLUGIN_AUTH_SSO_STATIC_ORGANIZATION. O Auth então não compara o domínio do email com a organização. A descoberta não revela identificadores do tenant. Um email desconhecido recebe a mesma resposta geral que um tenant sem SSO.

​

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

---