Autentisering

Konfigurer innlogging i en Kubernetes-distribusjon – OIDC, SAML, LDAP, offentlig tilgang, reCAPTCHA og passordregler.

Alle innloggingsmetoder kjører i web-tjenesten i hver Ayakaleaf Pro-pod. Ingen av dem trenger en ekstra pod eller en periodisk jobb, og alle holder innloggingstilstanden i sesjonen i Redis, så de fungerer likt med én eller flere replikaer. Det som skiller seg ut på Kubernetes, er hvor innstillinger, hemmeligheter og sertifikater plasseres, og hvilke nettverksstier som må være åpne:

Metode	Secret overleaf-secrets	Secret overleaf-certs	Podene må nå
OIDC	OVERLEAF_OIDC_CLIENT_SECRET	din CA, hvis privat	token- og userinfo-endepunktene til OP-en
SAML	–	IdP-sertifikatet, Overleafs egen nøkkel	ingenting: meldingene går via nettleseren
LDAP	OVERLEAF_LDAP_BIND_CREDENTIALS	LDAP-CA-en, hvis privat	LDAP-serveren
Offentlig tilgang	SMTP-passord, for aktiverings-e-poster	–	SMTP-serveren
reCAPTCHA	RECAPTCHA_SECRET_KEY, DEVICE_HISTORY_SECRET	–	www.google.com (eller RECAPTCHA_ENDPOINT)
Passordbegrensninger	–	–	–

EXTERNAL_AUTH slår på SSO-metodene, som en mellomromsseparert liste i ConfigMap-en, for eksempel EXTERNAL_AUTH: ldap oidc. Kontoer og hva brukere kan endre når SSO er på, er det samme som i Toolkit, se Autentisering.

En metode med feil innstillinger hindrer ikke poden i å bli klar: web logger error setting up passport in modules i /var/log/overleaf/web.log, og den metoden, samt de som kommer etter den i rekkefølgen ldap, saml, oidc, forblir av. Sjekk loggen etter hver endring. Vi prøvde det med EXTERNAL_AUTH: saml oidc og et manglende IdP-sertifikat: poden ble klar, og både /saml/login og /oidc/login svarte «Something went wrong» (500) til sertifikatstien ble rettet.

OIDC-autentisering

SAML-autentisering

LDAP-autentisering

Offentlig tilgang

reCAPTCHA

Passordbegrensninger