Uwierzytelnianie

Konfiguracja logowania we wdrożeniu Kubernetes - OIDC, SAML, LDAP, dostęp publiczny, reCAPTCHA i zasady haseł.

Wszystkie metody logowania działają w usłudze web każdego poda Ayakaleaf Pro. Żadna z nich nie wymaga dodatkowego poda ani zadania okresowego, a wszystkie przechowują stan logowania w sesji w Redis, więc działają tak samo z jedną repliką, jak i z kilkoma. Na Kubernetes różni się to, gdzie trafiają ustawienia, sekrety i certyfikaty oraz które ścieżki sieciowe muszą być otwarte:

Metoda	Secret overleaf-secrets	Secret overleaf-certs	Pody muszą mieć dostęp do
OIDC	OVERLEAF_OIDC_CLIENT_SECRET	Twój CA, jeśli prywatny	punktów końcowych token i userinfo dostawcy OP
SAML	–	certyfikat IdP, własny klucz Overleaf	niczego: komunikaty przechodzą przez przeglądarkę
LDAP	OVERLEAF_LDAP_BIND_CREDENTIALS	CA serwera LDAP, jeśli prywatny	serwera LDAP
Dostęp publiczny	hasło SMTP, dla e-maili aktywacyjnych	–	serwera SMTP
reCAPTCHA	RECAPTCHA_SECRET_KEY, DEVICE_HISTORY_SECRET	–	www.google.com (lub RECAPTCHA_ENDPOINT)
Ograniczenia haseł	–	–	–

EXTERNAL_AUTH włącza metody SSO jako lista rozdzielona spacjami w ConfigMap, na przykład EXTERNAL_AUTH: ldap oidc. Konta oraz to, co użytkownicy mogą zmieniać przy włączonym SSO, są takie same jak w Toolkit, zobacz Uwierzytelnianie.

Metoda z błędnymi ustawieniami nie powstrzymuje poda przed osiągnięciem gotowości: web zapisuje error setting up passport in modules w /var/log/overleaf/web.log, a ta metoda oraz metody następujące po niej w kolejności ldap, saml, oidc pozostają wyłączone. Sprawdzaj log po każdej zmianie. Wypróbowaliśmy to z EXTERNAL_AUTH: saml oidc i brakującym certyfikatem IdP: pod stał się gotowy, a zarówno /saml/login, jak i /oidc/login odpowiadały „Something went wrong” (500), dopóki ścieżka certyfikatu nie została poprawiona.

Uwierzytelnianie OIDC

Uwierzytelnianie SAML

Uwierzytelnianie LDAP

Dostęp publiczny

reCAPTCHA

Ograniczenia haseł