Автентифікація

Налаштування входу в розгортанні Kubernetes - OIDC, SAML, LDAP, публічний доступ, reCAPTCHA і правила паролів.

Усі методи входу працюють у службі web кожного пода Ayakaleaf Pro. Жоден із них не потребує додаткового пода чи періодичного завдання, і всі вони зберігають стан входу в сесії в Redis, тож однаково працюють з однією реплікою або кількома. У Kubernetes відрізняється лише те, куди потрапляють налаштування, секрети й сертифікати та які мережеві шляхи мають бути відкриті:

Метод	Secret overleaf-secrets	Secret overleaf-certs	Поди мають мати доступ до
OIDC	OVERLEAF_OIDC_CLIENT_SECRET	ваш CA, якщо приватний	кінцевих точок token і userinfo OP
SAML	–	сертифікат IdP, власний ключ Overleaf	нічого: повідомлення проходять через браузер
LDAP	OVERLEAF_LDAP_BIND_CREDENTIALS	CA LDAP, якщо приватний	сервера LDAP
Публічний доступ	пароль SMTP, для листів активації	–	сервера SMTP
reCAPTCHA	RECAPTCHA_SECRET_KEY, DEVICE_HISTORY_SECRET	–	www.google.com (або RECAPTCHA_ENDPOINT)
Обмеження паролів	–	–	–

EXTERNAL_AUTH вмикає методи SSO у вигляді списку, розділеного пробілами, у ConfigMap, наприклад EXTERNAL_AUTH: ldap oidc. Облікові записи й те, що користувачі можуть змінювати з увімкненим SSO, такі самі, як і в Toolkit, див. Автентифікація.

Метод із неправильними налаштуваннями не заважає поду стати готовим: web записує error setting up passport in modules у /var/log/overleaf/web.log, і цей метод, а також ті, що йдуть після нього в порядку ldap, saml, oidc, залишаються вимкненими. Перевіряйте журнал після кожної зміни. Ми спробували це з EXTERNAL_AUTH: saml oidc і відсутнім сертифікатом IdP: под став готовим, а /saml/login і /oidc/login відповідали «Something went wrong» (500), доки шлях до сертифіката не було виправлено.

Автентифікація OIDC

Автентифікація SAML

Автентифікація LDAP

Публічний доступ

reCAPTCHA

Обмеження паролів