Come implementare SSO di accesso incrociato e auto-login senza reindirizzamenti del browser per gli utenti non loggati?

Naviga le tue risposte
4

Devo implementare una soluzione SSO con i seguenti requisiti:

  1. Cross-domain: supponiamo di avere a.com , b.com e sso.com . Se effettuo il login tramite a.com , non dovrei effettuare il login quando visito b.com .
  2. Centralizzato: utente non loggato facendo clic su "Login" su a.com viene mostrata una schermata di accesso ospitata su sso.com . Le credenziali sono controllate da sso.com nell'origine dati accessibile solo ad essa.
  3. Accesso automatico: se l'utente ha eseguito l'accesso a a.com e successivamente visita b.com , verrà eseguito immediatamente il login. Cioè, su b.com , invece di un collegamento "Login" , vogliamo mostrare subito il loro nome utente, ecc. senza la necessità di cliccare nulla.
  4. Nessun reindirizzamento per utenti anonimi: un'ampia maggioranza dei miei utenti utilizzerà i siti senza avere un account. Pertanto, quando arrivano per la prima volta a a.com o b.com , non ci deve essere un reindirizzamento rapido dell'intera pagina a sso.com e ritorno per controllare se sono connessi. Un tale reindirizzamento sarebbe negativo per SEO e latenza.

Per i pochi utenti che hanno effettuato l'accesso a a.com e poi vai a b.com (o viceversa), un reindirizzamento è accettabile.

Ci sono molti esempi sul web per SSO, specialmente con OAuth2, OpenID Connect e CAS, ma non sono riuscito a trovare una ricetta per questi requisiti specifici. La più vicina è la guida StackOverflow SSO ( qui ), ma hanno alcuni requisiti extra che non possiedo (ad es. l'accesso dovrebbe funzionare anche se il server SSO non funziona)

    
posta Jan Żankowski 18.12.2017 - 17:56
fonte

1 risposta

2

Mi sembra che questo schema OpenID Connect dovrebbe farlo. Nota che non sono un esperto di sicurezza, quindi non usarlo senza ulteriore conferma.

  1. L'utente è aperto a a.com , b.com , sso.com .
  2. L'utente va a a.com , fa clic su "Accedi".
  3. Reindirizza a sso.com , con l'URL di ritorno su a.com come param.
  4. L'utente fornisce credenziali valide. sso.com li accetta, reindirizza a a.com con Codice di autorizzazione come param. C'è anche un cookie di sessione SSO per sso.com sulla risposta di reindirizzamento.
  5. Il browser segue il reindirizzamento, query a.com . a.com server invia il codice di autorizzazione a sso.com nel backend, riceve token di accesso e amp; ID token, imposta cookie di sessione su a.com . L'utente ora ha effettuato l'accesso su a.com .
  6. L'utente va a b.com .
  7. Javascript su b.com esegue una chiamata CORS AJAX non presidiata a sso.com , a un endpoint personalizzato (ad esempio sso.com/has-sso-session ). L'endpoint risponde essenzialmente con true / false in base alla presenza del cookie SSO sulla richiesta.
  8. Se la risposta è:
    • true , Javascript reindirizza il browser a sso.com , con l'URL di ritorno su b.com come param. Ciò innesca l'autenticazione regolare OpenID Connect, che sarà automatica perché l'utente ha un cookie SSO. Alla fine di esso, b.com server invia il codice di autorizzazione a sso.com nel backend, riceve token di accesso e amp; ID token, imposta cookie di sessione su b.com . L'utente ora ha effettuato l'accesso su b.com .
    • false , Javascript imposta un cookie di sessione SSO check failed su b.com . Ciò impedisce ulteriori controlli durante la navigazione di b.com , a meno che l'utente non faccia clic su "Accedi".
risposta data 18.12.2017 - 17:57
fonte

Leggi altre domande sui tag

I misuratori di potenza intelligenti possono leggere le pressioni dei tasti su una tastiera cablata? Affidatevi ai vincoli dei nomi o alla valutazione intermedia della CA?