Todennus

Määritä kirjautumiset Kubernetes-käyttöönotossa - OIDC, SAML, LDAP, julkinen pääsy, reCAPTCHA ja salasanasäännöt.

Kaikki kirjautumistavat toimivat jokaisen Ayakaleaf Pro -podin web-palvelussa. Mikään niistä ei tarvitse ylimääräistä podia tai ajastettua tehtävää, ja kaikki säilyttävät kirjautumistilansa Redisissä olevassa istunnossa, joten ne toimivat samoin yhdellä tai useammalla replikalla. Kubernetesissa eroaa se, minne asetukset, salaisuudet ja varmenteet sijoitetaan ja mitkä verkkoyhteydet on oltava auki:

Menetelmä	Secret overleaf-secrets	Secret overleaf-certs	Podien on tavoitettava
OIDC	OVERLEAF_OIDC_CLIENT_SECRET	oma CA:si, jos yksityinen	OP:n token- ja userinfo-päätepisteet
SAML	–	IdP:n varmenne, Overleafin oma avain	ei mitään: viestit kulkevat selaimen kautta
LDAP	OVERLEAF_LDAP_BIND_CREDENTIALS	LDAP:n CA, jos yksityinen	LDAP-palvelin
Julkinen käyttö	SMTP-salasana aktivointisähköposteja varten	–	SMTP-palvelin
reCAPTCHA	RECAPTCHA_SECRET_KEY, DEVICE_HISTORY_SECRET	–	www.google.com (tai RECAPTCHA_ENDPOINT)
Salasanarajoitukset	–	–	–

EXTERNAL_AUTH ottaa SSO-menetelmät käyttöön välilyönnein erotettuna luettelona ConfigMapissa, esimerkiksi EXTERNAL_AUTH: ldap oidc. Tilit ja se, mitä käyttäjät voivat muuttaa SSO:n ollessa käytössä, ovat samat kuin Toolkitissa, katso Todennus.

Menetelmä, jonka asetukset ovat virheelliset, ei estä podia tulemasta valmiiksi: web kirjaa error setting up passport in modules tiedostoon /var/log/overleaf/web.log, ja kyseinen menetelmä sekä sen jälkeen järjestyksessä ldap, saml, oidc tulevat menetelmät jäävät pois käytöstä. Tarkista loki jokaisen muutoksen jälkeen. Kokeilimme tätä asetuksella EXTERNAL_AUTH: saml oidc ja puuttuvalla IdP-varmenteella: pod tuli valmiiksi, ja sekä /saml/login että /oidc/login vastasivat ”Something went wrong” (500), kunnes varmenteen polku korjattiin.

OIDC-todennus

SAML-todennus

LDAP-todennus

Julkinen käyttö

reCAPTCHA

Salasanarajoitukset