Sto installando un login CMS condiviso tra due organizzazioni, un blog per comunità progettato per facilitare l'accesso e l'altro è un'applicazione PHP personale per un'organizzazione non profit correlata, per tenere traccia dell'iscrizione e così via utilizzando CiviCRM e un DB personalizzato per la conservazione dei record aziendali.
La composizione degli accessi allo staff è un sottoinsieme variabile di utenti noti come utenti CMS, che hanno riconosciuto accessi. La composizione degli utenti del blog 100% degli utenti di CMS. (Come gli utenti di Stack di Exchange e gli utenti di Stack di Exchange con accesso all'account su Server Fault). Inoltre, il blog è rivolto a un gruppo eterogeneo di utenti, alcuni dei quali non sono su Facebook ecc. E altri sono solo su Facebook ecc. Quindi qualsiasi cosa che non sia un accesso condiviso servirebbe da barriera .
Per impedire agli account stranieri dirottati di ottenere automaticamente l'accesso al personale, gli utenti noti riceveranno privilegi di personale sul lato delle app aziendali attraverso una whitelist di privilegi utente di utenti noti con > 1 privilegio (0 = non registrato nel guest) accoppiato con un login secondario OAuth (staff ID) all'interno del modulo OpenID dell'app client. L'accesso secondario OAuth sarebbe una ricerca in-app per utente una volta che l'identità OpenID è stata stabilita. L'idea è che molti utenti sarebbero già registrati nel sito principale (blog) e quindi riconosciuti.
Il nostro attuale supporto tecnico / tecnico conosce HybridAuth e lo raccomanda come plug-in per moduli PHP personalizzati da interfacciare con account di accesso CMS esistenti e anche con Facebook, ecc. usando OAuth. HybridAuth dispone anche di OpenID, ma ha familiarità con l'utilizzo di OAuth.
Sulla base della mia lettura preferirei utilizzare OpenID poiché ciò renderebbe l'app PHP riutilizzabile non dipendente da un'istanza Drupal single-client per gli accessi.
L'istanza dell'app può ancora essere associata a una libreria Drupal non specifica dell'istanza per l'installazione CMS.
Tuttavia, la mia preferenza si basa sui seguenti presupposti:
-
Che HybridAuth è in grado di implementare una versione sicura e intuitiva di OpenID. Poiché HybridAuth ha apparentemente una buona libreria OAuth e supporta OpenID, è un buon sostituto anche per OpenID Connect? Ha una simile funzionalità OpenID?
-
Che OpenID / Connect possono ora essere configurati in modo user-friendly per consentire l'identificazione email per emittente? (Lo confinerei con emittenti come Google e Facebook che consentono email, o combo di password via email, a utenti id univoci, e configurano l'accesso locale di conseguenza.)
-
Ora OpenID / Connect può essere configurato in modo intuitivo per consentire l'accesso fuori sede tramite emittente (ad esempio "accedi con Google o Facebook") in-frame o senza dover passare attraverso più pagine , preferibilmente senza uscire dal sito principale.
-
Che Drupal o CMS ospitato da client simile può essere usato come un emittente di OpenID per accessi locali direttamente o su un sito gemello, come fa Stack Exchange (presumo). Non so come funzionano gli accessi Drupal standard. È come un ID Drupal universale, o è specifico del sito e solo uno strato db? Drupal supporta solo il client OpenID login , non l'emittente OpenID? È il Drupal emittente specifico del sito, se esiste, ed è l'emittente di Drupal emittente?
-
Che HybridAuth e / o OpenID Connect consentono di connettersi tramite OpenID esistente (o connettersi con un solo clic se già connesso all'emittente) e poi OAuth ai servizi (solo personale dello staff).
-
Che HybridAuth e / o Drupal abbiano un modulo OpenID Emittente integrato per il sito padre che non richiede un dottorato. in PHP da installare.
Uno o più di questi presupposti sono errati? o non importa e dovrei usare solo OAuth? (Presumo che OAuth richieda la registrazione di ogni istanza di app con il CMS del cliente e i provider di social media scelti, tenere presente che l'app si trova su un dominio diverso ma correlato rispetto al blog stesso.)