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

Цю функцію розробив yu-i-i/overleaf-cep. Тут ми наводимо документацію для її налаштування.

Overleaf використовує бібліотеку passport-ldapauth, яка досить застаріла, тому повна сумісність з LDAP не гарантується. З деякими постачальниками ідентифікації LDAP (наприклад, https://goauthentik.io/) можуть виникати збої входу. Тому за можливості рекомендуємо насамперед використовувати метод OAuth/SAML. Для goauthentik дотримуйтеся наведеної нижче інструкції Покрокова інструкція: goauthentik, яку протестовано.

​

Що таке LDAP

LDAP — це протокол автентифікації, що використовується для зовнішньої перевірки особи. Overleaf Server Pro надає у вебінтерфейсі окрему форму входу через LDAP, відокремлену від стандартного методу автентифікації. Коли користувач надсилає своє ім’я користувача та пароль LDAP, бекенд Overleaf перевіряє облікові дані на налаштованому сервері LDAP, наприклад ldap://ldap:10389.

Приклад LDAP у Server Pro

​

Конфігурація

Усередині LDAP в Overleaf використовує бібліотеку passport-ldapauth. Більшість цих параметрів конфігурації передаються в об’єкт конфігурації server, який використовується для налаштування passport-ldapauth. Якщо у вас виникли проблеми з налаштуванням LDAP, варто прочитати README для passport-ldapauth, щоб зрозуміти, яку конфігурацію вона очікує.

Для ввімкнення модуля автентифікації LDAP потрібна змінна середовища EXTERNAL_AUTH. Вона визначає, які зовнішні методи автентифікації активовано. Значенням цієї змінної є список. Якщо список містить ldap, автентифікацію LDAP буде активовано.

Наприклад: EXTERNAL_AUTH=ldap saml

На відміну від Overleaf CEP, у нашій редакції ayaka-notes автентифікація LDAP обмежена роллю суто методу автентифікації, доступного за адресою http://your-overleaf.com/ldap/login.

Коли під час використання методів автентифікації LDAP користувач вводить у форму входу username і password, відбувається така спроба:

1. У каталозі LDAP виконується пошук користувача LDAP за фільтром, визначеним у OVERLEAF_LDAP_SEARCH_FILTER, і його автентифікація.
2. Якщо автентифікація успішна, у базі даних користувачів Overleaf шукається користувач, основна адреса електронної пошти якого збігається з адресою автентифікованого користувача LDAP:
   • Якщо відповідного користувача знайдено, поле hashedPassword цього користувача видаляється (якщо воно існує). Це гарантує, що надалі користувач зможе входити лише через автентифікацію LDAP.
   • Якщо відповідного користувача не знайдено, створюється новий користувач Overleaf з електронною поштою, ім’ям і прізвищем, отриманими із сервера LDAP.

Для користувачів, які входять через LDAP, ми не зберігаємо хешованих паролів у базі даних mongo Overleaf (а наявні видаляємо).

​

Змінні середовища

• OVERLEAF_LDAP_URL (обов’язкова)
  • URL сервера LDAP.
    • Приклад: ldaps://ldap.example.com:636 (LDAP через SSL)
    • Приклад: ldap://ldap.example.com:389 (без шифрування або STARTTLS, якщо налаштовано).
• OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
  • Відображувана назва служби ідентифікації LDAP, що використовується на сторінці входу.
  • За замовчуванням Log in with LDAP Provider.
• OVERLEAF_LDAP_EMAIL_ATT
  • Атрибут електронної пошти, що повертає сервер LDAP, за замовчуванням mail. Кожен користувач LDAP повинен мати щонайменше одну адресу електронної пошти. Якщо надано кілька адрес, використовується лише перша.
• OVERLEAF_LDAP_FIRST_NAME_ATT
  • Назва властивості, що містить ім’я користувача, яке використовується в застосунку, зазвичай givenName.
• OVERLEAF_LDAP_LAST_NAME_ATT
  • Назва властивості, що містить прізвище користувача, яке використовується в застосунку, зазвичай sn.
• OVERLEAF_LDAP_NAME_ATT
  • Назва властивості, що містить повне ім’я користувача, зазвичай cn. Якщо одну з двох попередніх змінних не визначено, ім’я та/або прізвище користувача витягується з цієї змінної. В іншому разі вона не використовується.
• OVERLEAF_LDAP_PLACEHOLDER
  • Заповнювач для форми входу, за замовчуванням Username.
• OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
  • Якщо встановлено true, поля first_name і last_name користувача LDAP оновлюються під час входу, а форма даних користувача на сторінці /user/settings для користувачів LDAP вимикається. В іншому разі дані отримуються лише під час першого входу.
• OVERLEAF_LDAP_BIND_DN
  • Відокремлене ім’я (DN) користувача LDAP, яке слід використовувати для з’єднання з LDAP (цей користувач повинен мати змогу шукати/переглядати облікові записи на сервері LDAP), наприклад cn=ldap_reader,dc=example,dc=com. Якщо не визначено, використовується анонімна прив’язка.
• OVERLEAF_LDAP_BIND_CREDENTIALS
  • Пароль для OVERLEAF_LDAP_BIND_DN.
• OVERLEAF_LDAP_BIND_PROPERTY
  • Властивість користувача для прив’язки до клієнта, за замовчуванням dn.
• OVERLEAF_LDAP_SEARCH_BASE (обов’язкова)
  • Базовий DN, від якого виконується пошук користувачів. Наприклад, ou=people,dc=example,dc=com.
• OVERLEAF_LDAP_SEARCH_FILTER
  • Фільтр пошуку LDAP для знаходження користувача. Використовуйте літерал ‘{{username}}’, щоб підставити в пошук LDAP введене ім’я користувача.
    • Приклад: (|(uid={{username}})(mail={{username}})) (користувач може входити за електронною поштою або логіном).
    • Приклад: (sAMAccountName={{username}}) (Active Directory).
• OVERLEAF_LDAP_SEARCH_SCOPE
  • Область пошуку може бути base, one або sub (за замовчуванням).
• OVERLEAF_LDAP_SEARCH_ATTRIBUTES
  • JSON-масив атрибутів, які потрібно отримати із сервера LDAP, наприклад ["uid", "mail", "givenName", "sn"]. За замовчуванням отримуються всі атрибути.
• OVERLEAF_LDAP_STARTTLS
  • Якщо true, використовується LDAP через TLS.
• OVERLEAF_LDAP_TLS_OPTS_CA_PATH
  • Шлях до файлу із сертифікатом CA, що використовується для перевірки SSL/TLS-сертифіката сервера LDAP. Якщо сертифікатів кілька, це може бути JSON-масив шляхів до сертифікатів. Файли мають бути доступні для Docker-контейнера.
    • Приклад (один сертифікат): /var/lib/overleaf/certs/ldap_ca_cert.pem
    • Приклад (кілька сертифікатів): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
• OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
  • Якщо true, сертифікат сервера перевіряється за списком наданих CA.
• OVERLEAF_LDAP_CACHE
  • Якщо true, до 100 облікових даних одночасно кешуватимуться на 5 хвилин.
• OVERLEAF_LDAP_TIMEOUT
  • Скільки часу клієнт дозволяє операціям тривати до тайм-ауту, мс (за замовчуванням: Infinity).
• OVERLEAF_LDAP_CONNECT_TIMEOUT
  • Скільки часу клієнт має чекати до тайм-ауту TCP-з’єднань, мс (за замовчуванням: значення ОС).
• OVERLEAF_LDAP_IS_ADMIN_ATT і OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
  • Якщо задано обидві змінні середовища, процес входу встановлює user.isAdmin = true, якщо профіль LDAP містить атрибут, указаний в OVERLEAF_LDAP_IS_ADMIN_ATT, і його значення або збігається з OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE, або є масивом, що містить OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE; в іншому разі user.isAdmin встановлюється в false. Якщо одну з цих змінних не задано, статус адміністратора встановлюється в true лише під час створення користувача-адміністратора в Launchpad.

Наведені нижче п’ять змінних використовуються для налаштування того, як контакти користувачів отримуються із сервера LDAP.

• OVERLEAF_LDAP_CONTACTS_FILTER
  • Фільтр для пошуку на сервері LDAP користувачів, яких буде завантажено в контакти. Заповнювач ‘{{userProperty}}’ у фільтрі замінюється значенням властивості, вказаної в OVERLEAF_LDAP_CONTACTS_PROPERTY, від користувача LDAP, який ініціює пошук. Якщо не визначено, користувачі із сервера LDAP не завантажуються в контакти.
• OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
  • Визначає базовий DN, від якого починається пошук контактів. За замовчуванням OVERLEAF_LDAP_SEARCH_BASE.
• OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
  • Область пошуку може бути base, one або sub (за замовчуванням).
• OVERLEAF_LDAP_CONTACTS_PROPERTY
  • Визначає властивість об’єкта користувача, яка замінить заповнювач ‘{{userProperty}}’ в OVERLEAF_LDAP_CONTACTS_FILTER.
• OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
  • Визначає значення OVERLEAF_LDAP_CONTACTS_PROPERTY, якщо пошук ініціює користувач, що не належить до LDAP. Якщо цю змінну не визначено, отриманий фільтр нічому не відповідатиме. Значення * можна використовувати як шаблон підстановки.

Приклад

OVERLEAF_LDAP_CONTACTS_FILTER=(gidNumber={{userProperty}})
OVERLEAF_LDAP_CONTACTS_PROPERTY=gidNumber
OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE=1000

Наведений приклад призводить до того, що в контакти поточного користувача LDAP завантажуються всі користувачі LDAP з тим самим UNIX gid. Користувачі, що не належать до LDAP, матимуть у своїх контактах усіх користувачів LDAP з UNIX gid=1000.

Приклад файлу variables.env

OVERLEAF_APP_NAME="Our Overleaf Instance"

ENABLED_LINKED_FILE_TYPES=project_file,project_output_file,url

# Enables Thumbnail generation using ImageMagick
ENABLE_CONVERSIONS=true

# Disables email confirmation requirement
EMAIL_CONFIRMATION_DISABLED=true

## Nginx
# NGINX_WORKER_PROCESSES=4
# NGINX_WORKER_CONNECTIONS=768

## Set for TLS via nginx-proxy
# OVERLEAF_BEHIND_PROXY=true
# OVERLEAF_SECURE_COOKIE=true

OVERLEAF_SITE_URL=http://my-overleaf-instance.com
OVERLEAF_NAV_TITLE=Our Overleaf Instance
# OVERLEAF_HEADER_IMAGE_URL=http://somewhere.com/mylogo.png
OVERLEAF_ADMIN_EMAIL=[e-mail]

OVERLEAF_LEFT_FOOTER=[{"text": "Contact your support team", "url": "mailto:[e-mail]"}]
OVERLEAF_RIGHT_FOOTER=[{"text":"Hello, I am on the Right", "url":"https://github.com/yu-i-i/overleaf-cep"}]

OVERLEAF_EMAIL_FROM_ADDRESS=[e-mail]
OVERLEAF_EMAIL_SMTP_HOST=smtp.example.com
OVERLEAF_EMAIL_SMTP_PORT=587
OVERLEAF_EMAIL_SMTP_SECURE=false
# OVERLEAF_EMAIL_SMTP_USER=
# OVERLEAF_EMAIL_SMTP_PASS=
# OVERLEAF_EMAIL_SMTP_NAME=
OVERLEAF_EMAIL_SMTP_LOGGER=false
OVERLEAF_EMAIL_SMTP_TLS_REJECT_UNAUTH=true
OVERLEAF_EMAIL_SMTP_IGNORE_TLS=false
OVERLEAF_CUSTOM_EMAIL_FOOTER=This system is run by department x

OVERLEAF_PROXY_LEARN=true
NAV_HIDE_POWERED_BY=true

#################
## LDAP for CE ##
#################

EXTERNAL_AUTH=ldap
OVERLEAF_LDAP_URL=ldap://ldap.example.com:389
OVERLEAF_LDAP_STARTTLS=true
OVERLEAF_LDAP_TLS_OPTS_CA_PATH=/var/lib/overleaf/certs/ldap_ca_cert.pem
OVERLEAF_LDAP_SEARCH_BASE=ou=people,dc=example,dc=com
OVERLEAF_LDAP_SEARCH_FILTER=(|(uid={{username}})(mail={{username}}))
OVERLEAF_LDAP_BIND_DN=cn=ldap_reader,dc=example,dc=com
OVERLEAF_LDAP_BIND_CREDENTIALS=GoodNewsEveryone
OVERLEAF_LDAP_EMAIL_ATT=mail
OVERLEAF_LDAP_FIRST_NAME_ATT=givenName
OVERLEAF_LDAP_LAST_NAME_ATT=sn
# OVERLEAF_LDAP_NAME_ATT=cn
OVERLEAF_LDAP_SEARCH_ATTRIBUTES=["uid", "sn", "givenName", "mail"]

OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN=true

OVERLEAF_LDAP_PLACEHOLDER='Username or email address'

OVERLEAF_LDAP_IS_ADMIN_ATT=mail
OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE=[e-mail]

OVERLEAF_LDAP_CONTACTS_FILTER=(gidNumber={{userProperty}})
OVERLEAF_LDAP_CONTACTS_PROPERTY=gidNumber
OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE='*'

​

Покрокова інструкція: goauthentik

Тут описано налаштування, протестоване з goauthentik. У прикладах використовується Base DN dc=example,dc=com; замініть його на свій.

1. Створіть обліковий запис для прив'язки

   Спочатку Overleaf входить до каталогу з власним обліковим записом, щоб знайти користувача. В Authentik відкрийте Directory > Users, натисніть New User, виберіть Internal User і натисніть Next. Введіть ім’я користувача, наприклад ldapservice, і натисніть Create:

   

   Authentik: створення облікового запису для прив'язки

   Відкрийте нового користувача та натисніть Set password. Цей пароль вказується в OVERLEAF_LDAP_BIND_CREDENTIALS:

   

   Authentik: встановлення пароля облікового запису для прив'язки (тестовий екземпляр)

   Запам’ятайте номер користувача в адресному рядку, наприклад 19 у …/#/identity/users/19. Він знадобиться на кроці 3.

2. Створіть постачальника та застосунок

   Відкрийте Applications > Applications і натисніть New Application. Майстер створює застосунок і його постачальника разом.

   1. Задайте застосунку назву та slug, наприклад overleaf-ldap, і натисніть Next:

   

   Authentik: назва та slug застосунку

   2. Виберіть LDAP Provider і натисніть Next:

   

   Authentik: вибір постачальника LDAP

   3. Встановіть Bind Mode на Direct binding, а Search Mode — на Direct querying:

   

   Authentik: режими прив'язки та пошуку постачальника LDAP

   4. Нижче встановіть Bind Flow на default-authentication-flow, а Base DN — на ваш Base DN, наприклад dc=example,dc=com:

   

   Authentik: bind flow і Base DN постачальника LDAP

   5. Натискайте Next до останньої сторінки та надішліть застосунок.

3. Дозвольте обліковому запису для прив'язки шукати в каталозі

   Без цього дозволу обліковий запис для прив’язки бачить лише себе, пошук не знаходить жодного користувача, і кожен вхід через LDAP завершується невдачею.

   Відкрийте постачальника, перейдіть до Permissions і натисніть Assign Role Object Permission. У полі Role введіть номер із кроку 1 і виберіть ak-managed-role--user-<number>, потім увімкніть Search full LDAP directory:

   

   Authentik: надання обліковому запису для прив'язки дозволу на пошук (тестовий екземпляр)

   Після цього роль відображається з позначкою в колонці Search full LDAP directory:

   

   Authentik: дозволи постачальника LDAP (тестовий екземпляр)

4. Запустіть LDAP outpost

   Authentik відповідає на запити LDAP через outpost — окремий контейнер. Відкрийте Applications > Outposts, створіть outpost типу LDAP з вашим постачальником і розгорніть його, як описано в Authentik. Він слухає порт 389 хоста, на якому працює. Коли outpost підключено, він показує зелену позначку:

   

   Authentik: запущений LDAP outpost (тестовий екземпляр)

   OVERLEAF_LDAP_URL=ldap://ldap.example.com:389
   
5. Заповніть DN

   Сторінка постачальника показує Base DN і приклад у розділі How to connect:

   

   Authentik: огляд постачальника LDAP (тестовий екземпляр)

   Не копіюйте значення з прикладу як є:

   • Bind DN показує обліковий запис, з яким ви ввійшли. Натомість використайте обліковий запис для прив’язки з кроку 1: cn=ldapservice,ou=users,<Base DN>.
   • Search base показує Base DN. Використайте ou=users,<Base DN>.

   OVERLEAF_LDAP_BIND_DN=cn=ldapservice,ou=users,dc=example,dc=com
   OVERLEAF_LDAP_BIND_CREDENTIALS=<password of ldapservice>
   OVERLEAF_LDAP_SEARCH_BASE=ou=users,dc=example,dc=com
   OVERLEAF_LDAP_SEARCH_FILTER=(cn={{username}})
   

   Authentik зберігає групу з іменем кожного користувача в ou=virtual-groups. Пошук (cn=alice) у всьому Base DN знаходить і cn=alice,ou=users,…, і cn=alice,ou=virtual-groups,…, а Overleaf відхиляє вхід, що відповідає більш ніж одному запису. Залишайте базу пошуку ou=users,<Base DN>.

6. Перевірте пошук

   Перш ніж запускати Overleaf, виконайте пошук, який він робитиме. Він має вивести рівно один dn::

   ldapsearch -x -H ldap://ldap.example.com:389 \
     -D cn=ldapservice,ou=users,dc=example,dc=com -w '<password of ldapservice>' \
     -b ou=users,dc=example,dc=com '(cn=alice)' dn
   

   Відсутність dn: зазвичай означає, що бракує дозволу з кроку 3.

7. Зіставте адміністраторів (необов'язково)

   Групи користувача містяться в memberOf у вигляді DN в ou=groups. Щоб члени групи Authentik Admins стали адміністраторами Overleaf:

   OVERLEAF_LDAP_IS_ADMIN_ATT=memberOf
   OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE=cn=Admins,ou=groups,dc=example,dc=com
   

   Прапорець адміністратора оновлюється під час кожного входу через LDAP. Якщо атрибут або значення неправильні, кожен адміністратор, який входить через LDAP, втрачає права адміністратора. Спершу протестуйте зіставлення з другим обліковим записом адміністратора.

Протестований variables.env для goauthentik

variables.env

EXTERNAL_AUTH=ldap
OVERLEAF_LDAP_IDENTITY_SERVICE_NAME=Log in with Authentik
OVERLEAF_LDAP_URL=ldap://ldap.example.com:389
OVERLEAF_LDAP_BIND_DN=cn=ldapservice,ou=users,dc=example,dc=com
OVERLEAF_LDAP_BIND_CREDENTIALS=<password of ldapservice>
OVERLEAF_LDAP_SEARCH_BASE=ou=users,dc=example,dc=com
OVERLEAF_LDAP_SEARCH_FILTER=(cn={{username}})
OVERLEAF_LDAP_EMAIL_ATT=mail
OVERLEAF_LDAP_NAME_ATT=name
OVERLEAF_LDAP_IS_ADMIN_ATT=memberOf
OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE=cn=Admins,ou=groups,dc=example,dc=com
OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN=true