Un buon protocollo SSO può essere costruito attorno a un server che firma i ticket anziché convalidarli su richiesta?

Question

Un buon protocollo SSO può essere costruito attorno a un server che firma i ticket anziché convalidarli su richiesta?

#1 da (4 voti)
#2 da (3 voti)

3

CAS e le sue alternative sembrano richiedere un flusso come questo quando un servizio funge da proxy per un utente quando accede a un servizio di back-end:

Il servizio A inoltra una richiesta al servizio B per conto di un utente. La richiesta include un token deperibile (ticket proxy) dal server di autenticazione. Il servizio B inoltra il token al server di autenticazione, chiedendo se è valido.

Sembra che potrebbe essere più efficiente avere il firmare del ticket di autenticazione e avere il Service B a conoscenza della chiave pubblica del server in modo che possa validare il ticket da solo, senza bisogno per la richiesta extra. Ovviamente tutte le funzionalità di single-sign-out dovrebbero essere lasciate al Service A, ma per il resto questo sembra tutto-upside: è più robusto di fronte alla latenza della rete o al server auth che scende, ed è ancora più difficile per la forza bruta di un token casuale.

Ci sono aspetti negativi o rischi che mi mancano? Qualcuno ha effettivamente implementato questo?

authentication sso pgp

posta histocrat 02.04.2013 - 20:14

fonte

2 risposte

Leggi altre domande sui tag authentication sso pgp

Devo usare SSL sul mio server di database? Meccanismo anti-CSRF con intestazione referer

score 4 · Answer 1

In una certa misura, ciò che suggerisci esiste: si chiama certificati X.509 .

I principali problemi con i token firmati sono:

Latenza di controllo: una volta che un token è stato firmato, non può essere cancellato immediatamente; devi aspettare la scadenza del token. Oppure implementa un controllo di revoca online (che si chiama OCSP nel caso dei certificati X.509), che ti riporta indietro al modello "server di autenticazione online".
Sincronizzazione dell'orologio: per imporre una data di scadenza, un verificatore deve avere un orologio ragionevolmente preciso, che può essere una sfida in un contesto di sicurezza. Infatti, i sistemi operativi moderni conoscono NTP fuori dalla scatola, ma NTP non è protetto.
Token firmati per autenticazione , non autorizzazione . Il server B vuole essere sicuro che stia parlando con il cliente giusto, ma vuole anche sapere se quel client è autorizzato ad accedere al servizio. Non è facile installare una matrice di autorizzazione generica all'interno di un token firmato. Chiunque abbia provato a lavorare con i certificati X.509 ha provato a usarli per l'autorizzazione e se ne è pentito.

Con un server di autenticazione online, con cui A e B parlano, il server di autenticazione può agire come un grosso interruttore di eliminazione, con annullamento immediato e anche possibile controllo delle autorizzazioni a grana fine.

score 3 · Answer 2

Se capisco correttamente il tuo esempio, sembra che stai parlando di applicare qualcosa come Kerberos a SSO. Finché il fornitore di servizi sa come fidarsi del ticket che garantisce il server di autenticazione, allora sì, dovrebbe essere sicuro.

Per quanto riguarda il motivo per cui non è fatto in questo modo, penso che potrebbe essere quello di fornire un maggiore controllo delle informazioni e tenerlo aggiornato. Quando il fornitore di servizi richiede in realtà dettagli sull'utente dal servizio stesso, è possibile aggiornare le informazioni in un'unica posizione e farle riflettere su più sistemi.

Se ho detto che sono AJ Henderson e che Facebook aveva firmato qualcosa che diceva che ero AJ Henderson, ma poi ho cambiato il mio nome in Bilbow Bagins, le informazioni firmate non avrebbero ottenuto l'aggiornamento, ma il token che collega il mio account sarebbe in grado di ottenere aggiornamenti. Inoltre, non deve preoccuparsi di cose come la scadenza delle firme poiché ogni controllo è fatto fresco. Ciò significa che sono necessari più scambi, ma anche un controllo più stretto.