2010-04-05 4 views
9

Attualmente sto testando un'implementazione OpenID e sto notando che Google invia un identificatore diverso per il nome host/nome di dominio che consumano diversi, anche per lo stesso utente. Ad esempio, Google invia un identificatore diverso quando il sito richiedente è localhost, rispetto all'identificatore che inviano quando il sito richiedente è 127.0.0.1 per lo stesso utente.L'identificativo OpenID di Google è diverso a seconda del nome di dominio "consumatore". Come evitare problemi se il nome di dominio deve cambiare?

Nota: non l'ho ancora testato utilizzando nomi di dominio pubblico, ma non riesco a capire perché il comportamento sarebbe diverso.

La mia preoccupazione per il comportamento di Google è che se in futuro decidessimo di cambiare il nome del dominio del nostro sito Web, gli utenti non potranno più accedere al sito Web utilizzando l'OpenId di Google come provider di identità. Questo sembra essere un grosso problema. Mi sto sfuggendo qualcosa, o tutti i siti che consumano OpenID si trovano di fronte a questo potenziale problema?

Ho anche provato questo con MyOpenId, ma l'identificatore che MyOpenId crea è fisso, quindi questo non sarebbe un problema con loro.

+2

http://blog.stackoverflow.com/2009/04/googles-openids-are-unique-per-domain/ –

+0

questo problema è stato risolto? – Jus12

risposta

3

Sembra che i OpenID URL restituiti da Google dipendono dal valore openid.realm che viene utilizzato. Inoltre, ho appena provato il processo OpenID con un dominio impostato su http://MYREALM e openid.return_to impostato su http://localhost/openid.php, ma ho ricevuto una richiesta non valida HTTP 400. Apparentemente, Google controlla che il regno abbia lo stesso dominio (e probabilmente la porta) come l'URL di "ritorno a".

Un'idea per un intervento consiste nel memorizzare l'indirizzo Gmail associato a OpenID. Ogni volta che richiedi un OpenID di Google, richiedi sempre l'indirizzo email dell'utente tramite il tipo http://axschema.org/contact/email di Attribute Exchange. Se cambi mai domini, puoi associare il nuovo URL OpenID al loro account in base all'indirizzo email.

Nota: È imperativo che si verifica la firma HMAC-SHA1. Altrimenti, chiunque sarebbe in grado di "tornare" all'azione OpenID checkover della tua applicazione Web con un indirizzo email costruito, consentendo loro di rilevare l'account di qualcuno se conoscono l'indirizzo Gmail del target.

Quando un utente accede con il proprio account Google per la prima volta dopo il passaggio, la procedura di migrazione è:

  1. inviare una richiesta POST per https://www.google.com/accounts/o8/ud con i seguenti parametri:

     
    +---------------------+----------------------------------+ 
    | openid.ns   | http://specs.openid.net/auth/2.0 | 
    | openid.mode   | associate      | 
    | openid.assoc_type | HMAC-SHA1      | 
    | openid.session_type | no-encryption     | 
    +---------------------+----------------------------------+ 
    

    (sostituire openid.realm=http://NEWREALM a seconda dei casi)

    La risposta sarà qualcosa di simile:

    012.351.
     
    ns:http://specs.openid.net/auth/2.0 
    session_type:no-encryption 
    assoc_type:HMAC-SHA1 
    assoc_handle:B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq 
    expires_in:46800 
    mac_key:F5XUXvoYutLvFv4IzJS0diytLmbe 
    
  2. Con il redirect alla URI servizio, https://www.google.com/accounts/o8/ud, modalità 'checkid_setup', assicurati di inviare l'assoc_handle che è stato ottenuto in precedenza così come richiedono l'indirizzo di posta elettronica dell'utente tramite Attribute Exchange.In altre parole, essere sicuri di inviare i seguenti, ulteriori parametri:

     
    +----------------------+----------------------------------------------------------+ 
    | openid.assoc_handle | B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq | 
    | openid.ns.ax   | http://openid.net/srv/ax/1.0        | 
    | openid.ax.mode  | fetch_request           | 
    | openid.ax.type.email | http://axschema.org/contact/email      | 
    | openid.ax.required | email             | 
    +----------------------+----------------------------------------------------------+ 
    

    Il "ritorno alla" richiesta includerà i parametri importanti openid_signed, openid_sig, e openid_ext1_value_email.

  3. Seguire the OpenID Authentication 2.0 Specification's procedure for generating the signature. Se la codifica base64 della firma HMAC-SHA1 non è uguale al valore openid_sig, la firma non è valida. Notare che il tasto MAC in questo esempio è F5XUXvoYutLvFv4IzJS0diytLmbe. Utilizza qualsiasi server di Google inviato indietro con la richiesta di associazione.

 

Google's Federated Login documentation page states che http://axschema.org/contact/email "[r] equests indirizzo Gmail dell'utente". Presumibilmente, una volta creato un account Google, l'indirizzo email "Gmail" è stato corretto. Ma, se questa ipotesi non è valida, allora non è sicuro da usare questa procedura perché un utente malintenzionato potrebbe cambiare il loro indirizzo di posta elettronica come restituito dalla Federated servizio di login a qualsiasi indirizzo di posta elettronica è il dell'account che desiderano rubare.

solo per essere al sicuro, prima di attivare la nuova OpenID, inviare una richiesta di verifica e-mail all'indirizzo di posta elettronica. Il link di verifica conterrebbe un nonce associato al nuovo OpenID. Una volta cliccato il link, il nuovo OpenID verrebbe completamente associato all'account dell'utente come ricevuta del nonce, verificherebbe l'associazione tra l'indirizzo email e il nuovo URL OpenID.

Consulta anche: openid.sig -- How is it generated?

+0

sulla memorizzazione di e-mail (io faccio questo), ma controllando l'HMAC-SHA1 non sono sicuro, perché sto usando il lib di DonNetOpen Auth per openid quindi probabilmente la lib lo fa – Omu

+0

@ChuckNorris: Sembra che ci sono classi nello spazio dei nomi 'DotNetOpenAuth.OpenId' per gestire le associazioni, ma non sono sicuro di quale fase del processo di autenticazione OpenID siano utilizzate. Le richieste "ritorno a" di OpenID 2.0 contengono un handle_braccio che può essere utilizzato dall'app Web per verificare che le informazioni provengano dal Servizio. L'app Web effettua semplicemente una richiesta POST all'URI del servizio con la modalità 'check_authentication' e tutti i parametri a cui si fa riferimento nel valore del parametro 'openid.signed'. Vedi [11.4.2. Verifica diretta con il provider OpenID] (http://tinyurl.com/3ffesj9). –

+0

@ChuckNorris: immagino solo che l'URI del servizio sia 'https: // www.google.com/accounts/o8/ud' se l'identità restituita inizia con' https://www.google.com/accounts/ O8/'. In altre parole, non permettere a nessun provider OpenID di inviare un OpenID di Google. Assicurati che sia di Google. –

1

c'è un altro possibile work-around. Quando si effettua la richiesta di autenticazione indiretta (reindirizzamento al Servizio URI), inviare il vecchio URL OpenID come i valori delle openid.claimed_id e openid.identity parametri anche se regno è impostato per il nuovo regno.

Sulla mia macchina di sviluppo, ho il dominio 'ThisComputer' alias di 127.0.0.1. Quando ho chiesto di autenticazione da OpenID Provider di Google, regno 'http: // ThisComputer' e openid.identity e openid.claimed_id entrambi impostati su http://specs.openid.net/auth/2.0/identifier_select, sono tornato qualcosa di simile:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

Ho quindi chiesto di autenticazione dall'OP, regno 'http : // localhost' e openid.identity e openid.claimed_id entrambi impostati http://specs.openid.net/auth/2.0/identifier_select. Sono tornato qualcosa di simile:

https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ

Ho quindi chiesto di autenticazione dall'OP, regno 'http: // localhost' e openid.identity e openid.claimed_id entrambi impostati https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ (l'identità OpenID per il mio account Google quando reame è 'http ://questo computer'). Sono tornato:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

Cioè, sono tornato lo stesso URL identità OpenID come quando regno è 'http: // ThisComputer'. Pertanto, anche se ho "migrato" la mia app Web che si basa su OpenID da "thiscomputer" a "localhost", posso ancora usare il vecchio URL di identità OpenID.

Questa soluzione funziona finché si conosce il vecchio URL di identità OpenID dell'utente, forse perché è memorizzato in un cookie.

Una nota: ho provato a installare openid.identity e openid.claimed_id a valori diversi (ad esempio, uno è http://specs.openid.net/auth/2.0/identifier_select mentre l'altro è https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ o uno è https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ e l'altro è https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ), ma il servizio OP di Google ha risposto con "La pagina richiesta non è valido ".

Problemi correlati