Oggi è ancora raccomandato il single sign-on con LDAP per integrare un gruppo di strumenti open source?

Stiamo conducendo un esercizio con un'istituzione pubblica per installare diversi strumenti open source affinché possano sperimentare e vedere ciò che più si addice a loro.

Pertanto, stiamo installando:

• una wiki (dokuwiki)
• mediagoblin
• gnu social
• Etherpad
• ethercalc

e forse un po 'di più.

Stavamo pensando di utilizzare LDAP per armonizzare gli accessi.

Ma spesso sembra che i plug-in LDAP non vengano più mantenuti e che la configurazione funzioni con difficoltà, alcuni strumenti hanno documenti LDAP insufficienti.

È ancora una buona idea oggi farlo tramite LDAP? OAuth è forse una scelta migliore?

So che questa non è una domanda di codice, ma ciò che vorremmo capire è se dovremmo attenerci alla nostra decisione di diventare LDAP o se dovremmo considerare altri percorsi. Grazie molto

LDAP non può fornire Single Sign On. C'è una grande differenza tra la possibilità di utilizzare gli stessi utenti e il Single Sign On, il che significa che accedi a tutti i sistemi contemporaneamente, con un unico modulo di accesso. Altrimenti, LDAP è perfettamente fattibile per utilizzare le stesse informazioni di accesso in tutti i sistemi.

OAuth è solo un protocollo per eseguire l'accesso e può utilizzare LDAP come backend per la gestione degli utenti.

Nel mondo universitario, il sistema CAS Apereo [ex Jasig] è un modo comune per eseguire Single Sign On per grandi suite di applicazioni web. Con CAS, l'utente immette sempre la propria password sul server di autenticazione: le singole applicazioni convalidano un ticket singolo anziché visualizzare la password dell'utente. Questa è una grande vittoria in termini di sicurezza quando si tratta di applicazioni sviluppate da molti gruppi e fornitori interni poiché nessuna delle applicazioni ha mai accesso alle password degli utenti.

Esistono numerose librerie CAS-client disponibili per la maggior parte degli ambienti di programmazione e il supporto CAS integrato sta diventando sempre più comune per le applicazioni utilizzate o vendute alle università. Oltre al principale "Jasig CAS Server" ci sono anche diversi server aggiuntivi disponibili, incluso Ruby CAS Server e un modulo per Drupal che può fungere da server CAS per autenticare applicazioni aggiuntive rispetto al database Drupal.

Lo stesso Jasig CAS Server è scritto in Java e può essere supportato da qualsiasi numero di gestori di autenticazione , tra cui:

• Banca dati
• JAAS
• LDAP
• eredità
• OAuth 1.0 / 2.0, OpenID
• RAGGIO
• SPNEGO (Windows)
• Attendibile (REMOTE_USER)
• X.509 (certificato SSL client)

Il server Jasig CAS può fungere da fonte di autenticazione per l'applicazione tramite una serie di protocolli diversi utilizzati per Single Sign On:

• Protocollo CAS 1/2/3
• Protocollo SAML 1.1 / 2.0
• Protocollo OAuth
• Protocollo OpenId

Può anche essere utilizzato come autenticazione dietro un provider Shibboleth o utilizzare un client Shibboleth come back-end di autenticazione.

Nota: l'organizzazione Jasig si sta fondendo con l'organizzazione Apereo, quindi alcuni URL potrebbero cambiare in futuro.