Skip to main content
Questa funzionalità è sviluppata da yu-i-i/overleaf-cep. Qui offriamo alcuni documenti per la tua configurazione.
Overleaf usa la libreria passport-ldapauth, che è relativamente datata, quindi la compatibilità LDAP non può essere pienamente garantita. Con alcuni provider di identità LDAP (ad esempio, https://goauthentik.io/) possono verificarsi errori di accesso. Pertanto, se possibile, si consiglia di preferire i metodi OAuth/SAML. Per goauthentik, segui la guida Passo dopo passo: goauthentik più sotto, che è stata testata.

​
Che cos’è LDAP

LDAP è un protocollo di autenticazione usato per la verifica dell’identità esterna. Overleaf Server Pro offre nell’interfaccia web un modulo di accesso LDAP dedicato, separato dal metodo di autenticazione standard. Quando un utente invia il proprio nome utente e la propria password LDAP, il backend di Overleaf verifica le credenziali sul server LDAP configurato, ad esempio ldap://ldap:10389.

Un esempio di LDAP in Server Pro

​
Configurazione

Internamente, l’LDAP di Overleaf usa la libreria passport-ldapauth. La maggior parte di queste opzioni di configurazione viene passata all’oggetto di configurazione server, usato per configurare passport-ldapauth. Se hai problemi a configurare LDAP, vale la pena leggere il README di passport-ldapauth per farti un’idea della configurazione che si aspetta. La variabile d’ambiente EXTERNAL_AUTH è necessaria per abilitare il modulo di autenticazione LDAP. Questa variabile d’ambiente specifica quali metodi di autenticazione esterna sono attivati. Il valore di questa variabile è un elenco. Se l’elenco include ldap, l’autenticazione LDAP verrà attivata. Ad esempio: EXTERNAL_AUTH=ldap saml A differenza di Overleaf CEP, nella nostra edizione ayaka-notes limitiamo l’autenticazione LDAP a un metodo di autenticazione puro, disponibile all’indirizzo http://your-overleaf.com/ldap/login. Quando si usano i metodi di autenticazione LDAP e un utente inserisce username e password nel modulo di accesso, si procede come segue:
  1. Viene cercato un utente LDAP nella directory LDAP usando il filtro definito da OVERLEAF_LDAP_SEARCH_FILTER e l’utente viene autenticato.
  2. Se l’autenticazione ha esito positivo, nel database degli utenti di Overleaf si cerca un utente con l’indirizzo email principale corrispondente all’indirizzo email dell’utente LDAP autenticato:
    • Se viene trovato un utente corrispondente, il campo hashedPassword di questo utente viene eliminato (se esiste). Ciò garantisce che in futuro l’utente possa accedere solo tramite autenticazione LDAP.
    • Se non viene trovato alcun utente corrispondente, viene creato un nuovo utente Overleaf usando l’email, il nome e il cognome recuperati dal server LDAP.
Per gli utenti che accedono tramite LDAP, non memorizziamo (o rimuoviamo quelli esistenti) gli hash delle password nel database mongo di Overleaf.

​
Variabili d’ambiente

  • OVERLEAF_LDAP_URL (obbligatoria)
    • URL del server LDAP.
      • Esempio: ldaps://ldap.example.com:636 (LDAP su SSL)
      • Esempio: ldap://ldap.example.com:389 (non cifrato o STARTTLS, se configurato).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Nome visualizzato del servizio di identità LDAP, usato nella pagina di accesso.
    • Valore predefinito: Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • L’attributo email restituito dal server LDAP, predefinito mail. Ogni utente LDAP deve avere almeno un indirizzo email. Se vengono forniti più indirizzi, verrà usato solo il primo.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Il nome della proprietà che contiene il nome dell’utente usato nell’applicazione, di solito givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Il nome della proprietà che contiene il cognome dell’utente usato nell’applicazione, di solito sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Il nome della proprietà che contiene il nome completo dell’utente, di solito cn. Se una delle due variabili precedenti non è definita, il nome e/o il cognome dell’utente vengono estratti da questa variabile. Altrimenti non viene usata.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Il segnaposto per il modulo di accesso, predefinito Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Se impostata su true, aggiorna i campi first_name e last_name dell’utente LDAP all’accesso e disattiva il modulo dei dettagli utente nella pagina /user/settings per gli utenti LDAP. Altrimenti, i dettagli verranno recuperati solo al primo accesso.
  • OVERLEAF_LDAP_BIND_DN
    • Il distinguished name dell’utente LDAP da usare per la connessione LDAP (questo utente deve poter cercare/elencare gli account sul server LDAP), ad es. cn=ldap_reader,dc=example,dc=com. Se non definito, viene usato il binding anonimo.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Password per OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Proprietà dell’utente con cui effettuare il bind sul client, predefinita dn.
  • OVERLEAF_LDAP_SEARCH_BASE (obbligatoria)
    • Il DN di base da cui cercare gli utenti. Ad es. ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • Filtro di ricerca LDAP con cui trovare un utente. Usa il letterale ‘{{username}}’ per far interpolare il nome utente fornito nella ricerca LDAP.
      • Esempio: (|(uid={{username}})(mail={{username}})) (l’utente può accedere con l’email o con il nome di login).
      • Esempio: (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • L’ambito della ricerca può essere base, one o sub (predefinito).
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • Array JSON di attributi da recuperare dal server LDAP, ad es. ["uid", "mail", "givenName", "sn"]. Per impostazione predefinita vengono recuperati tutti gli attributi.
  • OVERLEAF_LDAP_STARTTLS
    • Se true, viene usato LDAP su TLS.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Percorso del file contenente il certificato CA usato per verificare il certificato SSL/TLS del server LDAP. Se ci sono più certificati, può essere un array JSON di percorsi ai certificati. I file devono essere accessibili al container Docker.
      • Esempio (un certificato): /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Esempio (più certificati): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Se true, il certificato del server viene verificato rispetto all’elenco delle CA fornite.
  • OVERLEAF_LDAP_CACHE
    • Se true, verranno memorizzate nella cache fino a 100 credenziali alla volta per 5 minuti.
  • OVERLEAF_LDAP_TIMEOUT
    • Per quanto tempo il client deve lasciare attive le operazioni prima del timeout, in ms (predefinito: Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Per quanto tempo il client deve attendere prima del timeout sulle connessioni TCP, in ms (predefinito: valore predefinito del sistema operativo).
  • OVERLEAF_LDAP_IS_ADMIN_ATT e OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Quando entrambe le variabili d’ambiente sono impostate, il processo di accesso imposta user.isAdmin = true se il profilo LDAP contiene l’attributo specificato da OVERLEAF_LDAP_IS_ADMIN_ATT e il suo valore corrisponde a OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE oppure è un array che contiene OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE; altrimenti user.isAdmin viene impostato su false. Se una delle due variabili non è impostata, lo stato di amministratore viene impostato su true solo durante la creazione dell’utente amministratore nel Launchpad.
Le cinque variabili seguenti servono a configurare il modo in cui i contatti degli utenti vengono recuperati dal server LDAP.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Il filtro usato per cercare nel server LDAP gli utenti da caricare nei contatti. Il segnaposto ‘{{userProperty}}’ nel filtro viene sostituito con il valore della proprietà specificata da OVERLEAF_LDAP_CONTACTS_PROPERTY dell’utente LDAP che avvia la ricerca. Se non definito, nessun utente viene recuperato dal server LDAP nei contatti.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Specifica il DN di base da cui iniziare la ricerca dei contatti. Predefinito: OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • L’ambito della ricerca può essere base, one o sub (predefinito).
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Specifica la proprietà dell’oggetto utente che sostituirà il segnaposto ‘{{userProperty}}’ in OVERLEAF_LDAP_CONTACTS_FILTER.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Specifica il valore di OVERLEAF_LDAP_CONTACTS_PROPERTY se la ricerca viene avviata da un utente non LDAP. Se questa variabile non è definita, il filtro risultante non corrisponderà a nulla. Il valore * può essere usato come carattere jolly.
L’esempio sopra fa sì che nei contatti dell’utente LDAP corrente vengano caricati tutti gli utenti LDAP che hanno lo stesso gid UNIX. Gli utenti non LDAP avranno nei propri contatti tutti gli utenti LDAP con gid=1000 UNIX.

​
Passo dopo passo: goauthentik

Questa guida illustra una configurazione testata con goauthentik. Gli esempi usano il Base DN dc=example,dc=com; sostituiscilo con il tuo.
1

Crea un account di bind

Overleaf accede prima alla directory con un proprio account per trovare l’utente. In Authentik, apri Directory > Users, fai clic su New User, scegli Internal User e fai clic su Next. Inserisci un nome utente, ad esempio ldapservice, e fai clic su Create:

Authentik: crea l'account di bind

Apri il nuovo utente e fai clic su Set password. Questa password va in OVERLEAF_LDAP_BIND_CREDENTIALS:

Authentik: imposta la password dell'account di bind (istanza di test)

Annota il numero dell’utente nella barra degli indirizzi, ad esempio 19 in …/#/identity/users/19. Ti servirà nel passo 3.
2

Crea il provider e l'applicazione

Apri Applications > Applications e fai clic su New Application. La procedura guidata crea insieme l’applicazione e il relativo provider.1. Assegna all’applicazione un nome e uno slug, ad esempio overleaf-ldap, e fai clic su Next:

Authentik: nome e slug dell'applicazione

2. Scegli LDAP Provider e fai clic su Next:

Authentik: scegli il provider LDAP

3. Imposta Bind Mode su Direct binding e Search Mode su Direct querying:

Authentik: modalità di bind e di ricerca del provider LDAP

4. Più in basso, imposta Bind Flow su default-authentication-flow e Base DN sul tuo Base DN, ad esempio dc=example,dc=com:

Authentik: bind flow e Base DN del provider LDAP

5. Fai clic su Next fino all’ultima pagina e invia l’applicazione.
3

Consenti all'account di bind di cercare nella directory

Senza questo permesso l’account di bind vede solo se stesso, la ricerca non trova alcun utente e ogni accesso LDAP fallisce.Apri il provider, vai su Permissions e fai clic su Assign Role Object Permission. Come Role, digita il numero del passo 1 e seleziona ak-managed-role--user-<number>, quindi attiva Search full LDAP directory:

Authentik: concedi all'account di bind il permesso di ricerca (istanza di test)

Il ruolo mostra quindi un segno di spunta sotto Search full LDAP directory:

Authentik: permessi di un provider LDAP (istanza di test)

4

Esegui l'outpost LDAP

Authentik risponde alle richieste LDAP tramite un outpost, un container separato. Apri Applications > Outposts, crea un outpost di tipo LDAP con il tuo provider e distribuiscilo come descritto da Authentik. L’outpost resta in ascolto sulla porta 389 dell’host su cui è in esecuzione. Quando è connesso, mostra un segno di spunta verde:

Authentik: un outpost LDAP in esecuzione (istanza di test)

5

Compila i DN

La pagina del provider mostra il Base DN e un esempio sotto How to connect:

Authentik: panoramica di un provider LDAP (istanza di test)

Non copiare i valori di esempio così come sono:
  • Bind DN mostra l’account con cui hai effettuato l’accesso. Usa invece l’account di bind del passo 1: cn=ldapservice,ou=users,<Base DN>.
  • Search base mostra il Base DN. Usa ou=users,<Base DN>.
Authentik mantiene sotto ou=virtual-groups un gruppo con il nome di ogni utente. Una ricerca di (cn=alice) sull’intero Base DN trova sia cn=alice,ou=users,… sia cn=alice,ou=virtual-groups,…, e Overleaf rifiuta un accesso che corrisponde a più di una voce. Mantieni la search base su ou=users,<Base DN>.
6

Verifica la ricerca

Prima di avviare Overleaf, esegui la stessa ricerca che effettuerà Overleaf. Deve restituire esattamente un dn::
Se non compare alcun dn:, di solito manca il permesso del passo 3.
7

Mappa gli amministratori (facoltativo)

I gruppi di un utente si trovano in memberOf, come DN sotto ou=groups. Per rendere amministratori di Overleaf i membri del gruppo Authentik Admins:
Il flag di amministratore viene aggiornato a ogni accesso LDAP. Con un attributo o un valore errato, ogni amministratore che accede tramite LDAP perde i diritti di amministratore. Prova prima la mappatura con un secondo account amministratore.
variables.env
Ultima modifica il 6 ottobre 2026