Single Sign-On su più domini [chiuso]

110

La nostra azienda ha più domini configurati con un sito Web ospitato su ciascuno dei domini. In questo momento, ogni dominio ha la propria autenticazione che viene eseguita tramite cookie.

Quando qualcuno che ha effettuato l'accesso a un dominio deve accedere a qualsiasi cosa dall'altro dominio, l'utente deve accedere di nuovo utilizzando credenziali diverse sull'altro sito Web, situato sull'altro dominio.

Stavo pensando di passare al Single Sign On (SSO), in modo che questo problema possa essere eliminato. Apprezzerei qualsiasi idea su come questo potrebbe essere raggiunto, poiché non ho alcuna esperienza al riguardo.

Grazie.

Modifica: i siti Web sono un mix di siti Internet (esterni) e intranet (utilizzati internamente dall'azienda).

authentication single-sign-on

— Pascal
fonte

Sembra un lavoro per OpenID , ma consenti solo ID dal tuo dominio di accesso.

— Neall

2

@ Will Questa domanda potrebbe non essere per questo sito web nella rete SE, ma è decisamente costruttiva .

— Binar Web

@BinarWeb I motivi per chiudere si sono evoluti dal 2008. All'epoca questa era la scelta più applicabile.

91

La soluzione SSO che ho implementato qui funziona come segue:

C'è un dominio master, login.mydomain.com con lo script master_login.php che gestisce gli accessi.
Ogni dominio client ha lo script client_login.php
Tutti i domini hanno un database di sessioni utente condiviso.
Quando il dominio client richiede che l'utente abbia effettuato l'accesso, reindirizza al dominio master (login.mydomain.com/master_login.php). Se l'utente non ha effettuato l'accesso al master, richiede l'autenticazione dell'utente (ad esempio, visualizza la pagina di accesso). Dopo che l'utente è stato autenticato, crea una sessione in un database. Se l'utente è già autenticato, cerca il suo ID di sessione nel database.
Il dominio master ritorna al dominio client (client.mydomain.com/client_login.php) passando l'ID di sessione.
Il dominio del client crea un cookie che memorizza l'ID di sessione dal master. Il client può trovare l'utente connesso interrogando il database condiviso utilizzando l'ID di sessione.

Appunti:

L'id di sessione è un identificatore globale univoco generato con l'algoritmo da RFC 4122
Il master_login.php reindirizzerà solo ai domini nella sua whitelist
Il master e i client possono trovarsi in diversi domini di primo livello. Per esempio. client1.abc.com, client2.xyz.com, login.mydomain.com

— Grom
fonte

Questa sembra una buona soluzione grom. Cosa memorizzi nella banca dati? È (session_id, username, hashed_password)?

— Jon M

3

Come gestisci il caso in cui il dominio master login.mydomain.com non funzioni? A quel punto il login è impossibile?

— jjxtra

3

Qualche ente ha prodotto degli esempi di codice o un repository GitHub?

— Joshua F. Rountree

Questo è ciò che specificano quasi tutti i protocolli SSO (ad esempio SAML), ma con maggiore sicurezza contro gli attacchi di replay e così via.

— cweiske

2

E se non condividono il database degli utenti? Ogni app Web partner ha la propria base di utenti. Come lo incontriamo?

— stuckedoverflow

33

Non reinventare la ruota. Esistono numerosi pacchetti SSO cross-domain open source come JOSSO, OpenSSO, CAS, Shibboleth e altri. Se utilizzi la tecnologia Microsoft in tutto (IIS, AD), puoi invece utilizzare microsoft federation (ADFS).

— Markc
fonte

4

Assolutamente - ho visto troppe persone lanciare le proprie soluzioni di sicurezza solo per scoprire che sono vulnerabili a replay, XSRF o altri attacchi

5

+1 Non dovresti [quasi] mai reinventare la ruota della sicurezza.

— Mark E. Haase

13

OpenSSO è morto e JOSSO e CAS sono soluzioni JAVA. Solo un FYI

— OneHoopyFrood

15

Quanto sono diversi i nomi degli host?

Questi host possono condividere i cookie:

mail.xyz.com
www.xyz.com
logon.xyz.com

Ma questi non possono:

abc.com
xyz.com
www.tre.com

Nel primo caso puoi sbattere fuori una soluzione basata sui cookie. Pensa al GUID e a una tabella di sessione del database.

— jason saldo
fonte

2

Se utilizzi Active Directory, potresti fare in modo che ogni app utilizzi AD per l'autenticazione, quindi l'accesso potrebbe essere fluido.

Altrimenti, se le applicazioni possono parlare tra loro dietro le quinte, potresti usare sessionid e avere un'app che gestisce la generazione di id che serve tutte le tue altre applicazioni.

— Mike
fonte

2

l'utente non deve ancora inserire nome utente e password su dominio1.com e dominio2.com e dominio3.com quando accede a quei siti per la prima volta per questa sessione?

— HaBo