Gestione degli accessi dei dati dell'utente finale - Biglietti di autorizzazione per utente finale

Question

Gestione degli accessi dei dati dell'utente finale - Biglietti di autorizzazione per utente finale

#1 da (0 voti)

-2

Mi sono familiarizzato con White paper sul design per la sicurezza di Google . Per quanto posso capire, e rispetto a un'architettura di Micro-servizi, dalla sezione Gestione degli accessi degli utenti finali , lo schema di autenticazione di Google funziona come segue:

L'utente si autentica con il "Central Identity User Service" e riceve un token di sessione. Questo token è associato all'utente e memorizzato dal servizio di identità.
L'utente tenta di accedere a un servizio Google, (ad esempio Gmail), fornisce lì token di sessione (di solito come cookie).
Gmail passa il token di sessione degli utenti sul "Servizio di identità utente centrale" che ricerca la validità del token di sessione & concede un "ticket di autorizzazione dell'utente finale". Questo sembra essere un token basato sulle attestazioni firmato per consentire al servizio Gmail di passare ad altri servizi. Questo è probabilmente un token Web JSON firmato o simile, affermando che Gmail ha la mia autorità per accedere ai dati degli utenti. Questa firma può essere convalidata senza mai comunicare con il Central Identity Service basato su un segreto condiviso, suppongo che in questo caso Google utilizzi una coppia di chiavi pubblica / privata per la firma?

Il "Central User Identity Service" è davvero una singola istanza centrale, che condivide un unico backing store? Sembra così dato l'architettura e il nome. Come può essere dato che rappresenta un singolo punto di errore per Google? Mi manca qualcosa?

Sono pronto a credere che il "Servizio di identità utente centrale" possa essere in effetti più istanze più complesse?

Questo modello sembra causare molte chiacchiere tra il Servizio Gmail e il Servizio Identità Utente Centrale, il che significa che dovrebbe essere coinvolto in quasi tutte le richieste. Supponendo che il bilanciamento del carico sia non appiccicoso, la richiesta degli utenti di caricare la pagina n. 2 della posta in arrivo è più probabile che non colpire un'altra istanza del servizio Gmail. Memorizzazione nella cache locale degli utenti La validità del cookie di sessione rappresenta probabilmente un rischio che sarebbe comunque rispettata dopo la revoca?

C'è qualche documentazione pubblica o qualcuno che possa darmi una panoramica di quanto sia veramente centrale il "Servizio di identità utente centrale"?

authentication scalability google session

posta jammmie999 03.07.2017 - 22:06

fonte

1 risposta

Leggi altre domande sui tag authentication scalability google session

Qual è il pattern chiamato dove si spostano le proprietà statiche di una classe in una classe separata? [chiuso] cosa sono i contro e i pro tra i due progetti di controllo della versione di un progetto: repository multipli, vs repository singolo [duplicato]

score 0 · Answer 1

Is the "Central User Identity Service" really a central, single instance, sharing a single backing store?

Che cosa ti dà l'impressione che "Servizio di identità utente centrale" significhi una singola istanza? "Centrale" in questo schema di autenticazione significa che tutti i servizi comunicano con il servizio centrale (non necessariamente la stessa macchina). Google avrà scelto un'architettura sufficientemente ridondante e scalabile per questo servizio. "Servizio" è un termine astratto che non è associato a nessuna particolare strategia o architettura di implementazione.

How can this be given it represents a single point of failure for Google?

Sì, il servizio è un singolo punto di errore, ma nessuna singola macchina è un punto di errore per il servizio. Google ha probabilmente implementato istanze in regioni di tutto il mondo per aiutare a impedire che un servizio così critico non sia disponibile.

Non ho familiarità con il sistema di autenticazione di Google, ma ho implementato e utilizzato Central Authentication Service (CAS) prima, e il protocollo di autenticazione è molto simile a quello che descrivi. CAS è esso stesso scalabile orizzontalmente e consente di collegare il servizio a diversi back-end di archiviazione, il che consente di scegliere un back-end di archiviazione che sia anche scalabile.

I am poised to believe that the "Central User Identity Service" may in fact be several sharded instances?

Sharding è un metodo per ridimensionare orizzontalmente un sistema, ma non è l'unico modo. Ad esempio, potrebbero esserci un sacco di repliche dell'intero set di dati.

This pattern seems to cause a lot of chatter between the Gmail Service and the Central User Identity Service, meaning that it would need to be involved with nearly every request. Assuming that load balancing is non-sticky the users request to load page #2 of there inbox is more likely than not to hit another Gmail Service instance. Local caching of the users Session cookie's validity probably represents a risk that it would still be honored after revocation?

Con CAS, il servizio Gmail parla solo a CAS quando un utente che non ha una sessione autenticata con Gmail ma ha ricevuto un token di sessione per Gmail da CAS. In altre parole, Gmail parla solo con CAS una volta per verificare il token di sessione. Dopo aver verificato il token di sessione, Gmail deve creare una sessione autenticata per l'utente finale. Vedi questo diagramma di sequenza e nota che le seconde richieste colpiscono la sessione di Gmail e Gmail non parla con CAS.

a risk that it would still be honored after revocation?

In CAS ogni servizio è registrato con CAS, e quando l'utente si disconnette da CAS, CAS invia un segnala a ciascun servizio registrato in modo che possa cogliere l'opportunità di eliminare la sessione autenticata dell'utente.