Skip to main content
Ta funkcja została opracowana przez yu-i-i/overleaf-cep. Poniżej udostępniamy dokumentację, która pomoże Ci ją skonfigurować.
Overleaf korzysta z biblioteki passport-ldapauth, która jest stosunkowo przestarzała, dlatego nie można w pełni zagwarantować zgodności z LDAP. W przypadku niektórych dostawców tożsamości LDAP (na przykład https://goauthentik.io/) mogą występować błędy logowania. Dlatego, jeśli to możliwe, zalecamy w pierwszej kolejności korzystanie z metod OAuth/SAML. W przypadku goauthentik postępuj zgodnie z przetestowaną instrukcją Krok po kroku: goauthentik poniżej.

Czym jest LDAP

LDAP to protokół uwierzytelniania używany do zewnętrznej weryfikacji tożsamości. Overleaf Server Pro udostępnia w interfejsie webowym dedykowany formularz logowania LDAP, oddzielny od standardowej metody uwierzytelniania. Gdy użytkownik przesyła swoją nazwę użytkownika i hasło LDAP, backend Overleaf weryfikuje dane uwierzytelniające na skonfigurowanym serwerze LDAP, na przykład ldap://ldap:10389.

Przykład LDAP w Server Pro

Konfiguracja

Wewnętrznie mechanizm LDAP w Overleaf korzysta z biblioteki passport-ldapauth. Większość opcji konfiguracyjnych jest przekazywana do obiektu konfiguracyjnego server, który służy do konfigurowania passport-ldapauth. Jeśli masz problemy z konfiguracją LDAP, warto przeczytać README biblioteki passport-ldapauth, aby zorientować się, jakiej konfiguracji oczekuje. Do włączenia modułu uwierzytelniania LDAP wymagana jest zmienna środowiskowa EXTERNAL_AUTH. Określa ona, które zewnętrzne metody uwierzytelniania są aktywne. Wartością tej zmiennej jest lista. Jeśli lista zawiera ldap, uwierzytelnianie LDAP zostanie aktywowane. Na przykład: EXTERNAL_AUTH=ldap saml W odróżnieniu od Overleaf CEP, w naszej edycji ayaka-notes uwierzytelnianie LDAP ograniczamy do czystej metody uwierzytelniania, dostępnej pod adresem http://your-overleaf.com/ldap/login. Gdy używana jest metoda uwierzytelniania LDAP, a użytkownik wpisze w formularzu logowania username i password, wykonywane są następujące kroki:
  1. Użytkownik LDAP jest wyszukiwany w katalogu LDAP przy użyciu filtra zdefiniowanego w OVERLEAF_LDAP_SEARCH_FILTER, a następnie uwierzytelniany.
  2. Jeśli uwierzytelnienie się powiedzie, w bazie użytkowników Overleaf wyszukiwany jest użytkownik, którego główny adres e-mail odpowiada adresowi e-mail uwierzytelnionego użytkownika LDAP:
    • Jeśli zostanie znaleziony pasujący użytkownik, pole hashedPassword tego użytkownika jest usuwane (jeśli istnieje). Dzięki temu w przyszłości użytkownik będzie mógł logować się wyłącznie przez uwierzytelnianie LDAP.
    • Jeśli pasujący użytkownik nie zostanie znaleziony, tworzony jest nowy użytkownik Overleaf z adresem e-mail, imieniem i nazwiskiem pobranymi z serwera LDAP.
W przypadku użytkowników logujących się przez LDAP nie przechowujemy zahaszowanych haseł w bazie danych mongo Overleaf (a istniejące usuwamy).

Zmienne środowiskowe

  • OVERLEAF_LDAP_URL (wymagana)
    • Adres URL serwera LDAP.
      • Przykład: ldaps://ldap.example.com:636 (LDAP przez SSL)
      • Przykład: ldap://ldap.example.com:389 (bez szyfrowania lub STARTTLS, jeśli jest skonfigurowany).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Wyświetlana nazwa usługi tożsamości LDAP, używana na stronie logowania.
    • Domyślnie Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • Atrybut adresu e-mail zwracany przez serwer LDAP, domyślnie mail. Każdy użytkownik LDAP musi mieć co najmniej jeden adres e-mail. Jeśli podano kilka adresów, używany jest tylko pierwszy.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Nazwa właściwości zawierającej imię użytkownika używane w aplikacji, zwykle givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Nazwa właściwości zawierającej nazwisko użytkownika używane w aplikacji, zwykle sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Nazwa właściwości zawierającej pełne imię i nazwisko użytkownika, zwykle cn. Jeśli któraś z dwóch poprzednich zmiennych nie jest zdefiniowana, imię i/lub nazwisko użytkownika jest wyodrębniane z tej wartości. W przeciwnym razie nie jest ona używana.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Tekst zastępczy (placeholder) w formularzu logowania, domyślnie Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Jeśli ustawiona na true, przy logowaniu aktualizuje pola first_name i last_name użytkownika LDAP oraz wyłącza formularz danych użytkownika na stronie /user/settings dla użytkowników LDAP. W przeciwnym razie dane są pobierane tylko przy pierwszym logowaniu.
  • OVERLEAF_LDAP_BIND_DN
    • Nazwa wyróżniająca (DN) użytkownika LDAP, który ma być używany do połączenia z LDAP (ten użytkownik powinien mieć możliwość wyszukiwania/wyświetlania kont na serwerze LDAP), np. cn=ldap_reader,dc=example,dc=com. Jeśli nie jest zdefiniowana, używane jest wiązanie anonimowe.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Hasło dla OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Właściwość użytkownika używana do wiązania z klientem, domyślnie dn.
  • OVERLEAF_LDAP_SEARCH_BASE (wymagana)
    • Bazowy DN, od którego rozpoczyna się wyszukiwanie użytkowników. Np. ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • Filtr wyszukiwania LDAP służący do znalezienia użytkownika. Użyj literału ‘{{username}}’, aby podana nazwa użytkownika została wstawiona do wyszukiwania LDAP.
      • Przykład: (|(uid={{username}})(mail={{username}})) (użytkownik może logować się adresem e-mail lub nazwą logowania).
      • Przykład: (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • Zakres wyszukiwania może mieć wartość base, one lub sub (domyślnie).
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • Tablica JSON atrybutów pobieranych z serwera LDAP, np. ["uid", "mail", "givenName", "sn"]. Domyślnie pobierane są wszystkie atrybuty.
  • OVERLEAF_LDAP_STARTTLS
    • Jeśli true, używany jest LDAP przez TLS.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Ścieżka do pliku z certyfikatem CA używanym do weryfikacji certyfikatu SSL/TLS serwera LDAP. Jeśli certyfikatów jest kilka, może to być tablica JSON ze ścieżkami do certyfikatów. Pliki muszą być dostępne dla kontenera Docker.
      • Przykład (jeden certyfikat): /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Przykład (wiele certyfikatów): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Jeśli true, certyfikat serwera jest weryfikowany względem listy podanych CA.
  • OVERLEAF_LDAP_CACHE
    • Jeśli true, jednocześnie do 100 danych uwierzytelniających będzie przechowywanych w pamięci podręcznej przez 5 minut.
  • OVERLEAF_LDAP_TIMEOUT
    • Jak długo klient pozwala na trwanie operacji przed przekroczeniem limitu czasu, w ms (domyślnie: Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Jak długo klient czeka na nawiązanie połączenia TCP przed przekroczeniem limitu czasu, w ms (domyślnie: wartość domyślna systemu operacyjnego).
  • OVERLEAF_LDAP_IS_ADMIN_ATT i OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Gdy ustawione są obie zmienne środowiskowe, proces logowania ustawia user.isAdmin = true, jeśli profil LDAP zawiera atrybut wskazany przez OVERLEAF_LDAP_IS_ADMIN_ATT, a jego wartość jest równa OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE lub jest tablicą zawierającą OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE; w przeciwnym razie user.isAdmin jest ustawiane na false. Jeśli którakolwiek z tych zmiennych nie jest ustawiona, status administratora jest ustawiany na true tylko podczas tworzenia konta administratora w Launchpad.
Poniższe pięć zmiennych służy do konfigurowania sposobu pobierania kontaktów użytkownika z serwera LDAP.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Filtr używany do wyszukiwania na serwerze LDAP użytkowników, którzy mają zostać wczytani do kontaktów. Symbol zastępczy ‘{{userProperty}}’ w filtrze jest zastępowany wartością właściwości wskazanej przez OVERLEAF_LDAP_CONTACTS_PROPERTY użytkownika LDAP inicjującego wyszukiwanie. Jeśli zmienna nie jest zdefiniowana, żaden użytkownik nie jest pobierany z serwera LDAP do kontaktów.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Określa bazowy DN, od którego rozpoczyna się wyszukiwanie kontaktów. Domyślnie OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • Zakres wyszukiwania może mieć wartość base, one lub sub (domyślnie).
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Określa właściwość obiektu użytkownika, która zastąpi symbol zastępczy ‘{{userProperty}}’ w OVERLEAF_LDAP_CONTACTS_FILTER.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Określa wartość OVERLEAF_LDAP_CONTACTS_PROPERTY, jeśli wyszukiwanie inicjuje użytkownik spoza LDAP. Jeśli ta zmienna nie jest zdefiniowana, wynikowy filtr nie dopasuje niczego. Wartość * może być używana jako symbol wieloznaczny.
Powyższy przykład powoduje wczytanie do kontaktów bieżącego użytkownika LDAP wszystkich użytkowników LDAP, którzy mają ten sam UNIX-owy gid. Użytkownicy spoza LDAP będą mieli w kontaktach wszystkich użytkowników LDAP z UNIX-owym gid=1000.

Krok po kroku: goauthentik

Poniżej opisano konfigurację przetestowaną z goauthentik. W przykładach użyto Base DN dc=example,dc=com; zastąp go własnym.
1

Utwórz konto do wiązania (bind)

Overleaf najpierw loguje się do katalogu za pomocą własnego konta, aby znaleźć użytkownika. W Authentik otwórz Directory > Users, kliknij New User, wybierz Internal User i kliknij Next. Wpisz nazwę użytkownika, na przykład ldapservice, i kliknij Create:

Authentik: tworzenie konta do wiązania

Otwórz nowego użytkownika i kliknij Set password. To hasło należy wpisać do OVERLEAF_LDAP_BIND_CREDENTIALS:

Authentik: ustawianie hasła konta do wiązania (instancja testowa)

Zanotuj numer użytkownika widoczny w pasku adresu, na przykład 19 w …/#/identity/users/19. Będzie potrzebny w kroku 3.
2

Utwórz dostawcę i aplikację

Otwórz Applications > Applications i kliknij New Application. Kreator tworzy aplikację wraz z jej dostawcą.1. Nadaj aplikacji nazwę i slug, na przykład overleaf-ldap, i kliknij Next:

Authentik: nazwa i slug aplikacji

2. Wybierz LDAP Provider i kliknij Next:

Authentik: wybór dostawcy LDAP

3. Ustaw Bind Mode na Direct binding, a Search Mode na Direct querying:

Authentik: tryb wiązania i wyszukiwania dostawcy LDAP

4. Niżej ustaw Bind Flow na default-authentication-flow, a Base DN na swój Base DN, na przykład dc=example,dc=com:

Authentik: przepływ wiązania i Base DN dostawcy LDAP

5. Klikaj Next aż do ostatniej strony i zatwierdź aplikację.
3

Zezwól kontu do wiązania na przeszukiwanie katalogu

Bez tego uprawnienia konto do wiązania widzi tylko siebie, wyszukiwanie nie znajduje żadnego użytkownika i każde logowanie LDAP kończy się niepowodzeniem.Otwórz dostawcę, przejdź do Permissions i kliknij Assign Role Object Permission. W polu Role wpisz numer z kroku 1 i wybierz ak-managed-role--user-<number>, a następnie włącz Search full LDAP directory:

Authentik: nadawanie kontu do wiązania uprawnienia wyszukiwania (instancja testowa)

Rola pokazuje wtedy znacznik wyboru w kolumnie Search full LDAP directory:

Authentik: uprawnienia dostawcy LDAP (instancja testowa)

4

Uruchom outpost LDAP

Authentik obsługuje LDAP przez outpost, czyli osobny kontener. Otwórz Applications > Outposts, utwórz outpost typu LDAP ze swoim dostawcą i wdróż go zgodnie z opisem Authentik. Nasłuchuje on na porcie 389 hosta, na którym działa. Gdy jest połączony, wyświetla zielony znacznik:

Authentik: działający outpost LDAP (instancja testowa)

5

Uzupełnij DN

Strona dostawcy pokazuje Base DN i przykład w sekcji How to connect:

Authentik: przegląd dostawcy LDAP (instancja testowa)

Nie kopiuj przykładowych wartości bez zmian:
  • Bind DN pokazuje konto, na które jesteś zalogowany. Zamiast tego użyj konta do wiązania z kroku 1: cn=ldapservice,ou=users,<Base DN>.
  • Search base pokazuje Base DN. Użyj ou=users,<Base DN>.
Authentik przechowuje w ou=virtual-groups grupę o nazwie każdego użytkownika. Przeszukanie całego Base DN pod kątem (cn=alice) znajduje zarówno cn=alice,ou=users,…, jak i cn=alice,ou=virtual-groups,…, a Overleaf odrzuca logowanie pasujące do więcej niż jednego wpisu. Pozostaw bazę wyszukiwania ustawioną na ou=users,<Base DN>.
6

Sprawdź wyszukiwanie

Przed uruchomieniem Overleaf wykonaj wyszukiwanie, które będzie on przeprowadzał. Musi ono wypisać dokładnie jeden wiersz dn::
Brak jakiegokolwiek dn: zwykle oznacza, że brakuje uprawnienia z kroku 3.
7

Zmapuj administratorów (opcjonalnie)

Grupy użytkownika znajdują się w memberOf jako DN w ou=groups. Aby członkowie grupy Authentik Admins stali się administratorami Overleaf:
Flaga administratora jest aktualizowana przy każdym logowaniu LDAP. Przy błędnym atrybucie lub wartości każdy administrator logujący się przez LDAP traci uprawnienia administratora. Najpierw przetestuj mapowanie na drugim koncie administratora.
variables.env
Ostatnia modyfikacja 6 października 2026