Autenticação

Configure logins em uma implantação Kubernetes - OIDC, SAML, LDAP, acesso público, reCAPTCHA e regras de senha.

Todos os métodos de login são executados no serviço web de cada pod do Ayakaleaf Pro. Nenhum deles precisa de um pod extra ou de uma tarefa periódica, e todos mantêm o estado de login na sessão no Redis, então funcionam da mesma forma com uma ou várias réplicas. O que muda no Kubernetes é onde ficam as configurações, os segredos e os certificados, e quais caminhos de rede precisam estar abertos:

Método	Secret overleaf-secrets	Secret overleaf-certs	Os pods precisam alcançar
OIDC	OVERLEAF_OIDC_CLIENT_SECRET	sua CA, se for privada	os endpoints de token e userinfo do OP
SAML	–	o certificado do IdP, a chave própria do Overleaf	nada: as mensagens passam pelo navegador
LDAP	OVERLEAF_LDAP_BIND_CREDENTIALS	a CA do LDAP, se for privada	o servidor LDAP
Acesso público	senha SMTP, para e-mails de ativação	–	o servidor SMTP
reCAPTCHA	RECAPTCHA_SECRET_KEY, DEVICE_HISTORY_SECRET	–	www.google.com (ou RECAPTCHA_ENDPOINT)
Restrições de senha	–	–	–

EXTERNAL_AUTH ativa os métodos de SSO, como uma lista separada por espaços no ConfigMap, por exemplo EXTERNAL_AUTH: ldap oidc. As contas e o que os usuários podem alterar com SSO ativado são iguais aos do Toolkit; consulte Autenticação.

Um método com configurações incorretas não impede que o pod fique pronto: o web registra error setting up passport in modules em /var/log/overleaf/web.log, e esse método, junto com os que vêm depois dele na ordem ldap, saml, oidc, permanece desativado. Verifique o log após cada alteração. Testamos isso com EXTERNAL_AUTH: saml oidc e um certificado do IdP ausente: o pod ficou pronto, e tanto /saml/login quanto /oidc/login responderam “Something went wrong” (500) até que o caminho do certificado fosse corrigido.

Autenticação OIDC

Autenticação SAML

Autenticação LDAP

Acesso público

reCAPTCHA

Restrições de senha