Servizio di auth centrale che reindirizza al sottodominio, utilizzando la firma digitale come token di autenticazione

Ho visto uno schema molto simile al tuo usato in pratica, anche se con MAC segreto condiviso dove hai una chiave pubblica / privata. Non lo consiglierei, mi sembra complicato. Perdonami se vado lontano, ma vedendo i tuoi risultati, penso che tu non sia un programmatore sul lato server. Sembra che i programmatori sul lato server dei sottodomini siano i tuoi clienti principali qui: vuoi aiutarli con il tuo server di autenticazione centrale. Quindi suggerirei di consultare un programmatore del sottodominio e cercare di capire le loro esigenze e rendere il servizio estremamente semplice per loro (suggerimento: quello attuale non lo è).

Il difetto principale è che questo è costoso, sia in termini di tempo di programmazione (sul server centrale e sui sottodomini), ma anche a livello computazionale.

Un altro grande difetto è che quando scade un timeout, è necessario un codice piuttosto complicato per consentire all'utente di eseguire nuovamente l'autenticazione e continuare senza perdere il loro stato.

Rifletti su cosa fa il tuo servizio. La mia controproposta è che il vostro servizio stabilisce uno stato lato server e lo dà ai sottodomini in modo che possano successivamente utilizzarlo internamente. Lo stato inizialmente consiste di user_id, authenticated_until, authorized_subdomains, ma ovviamente qualunque cosa non banale possa fare il sottodominio, può aggiungere le sue stesse cose allo stesso stato.

Nella maggior parte dei framework che un sottodominio potrebbe utilizzare, è probabile che le sessioni vengano identificate con un token casuale (pensate a qualcosa come JSESSIONID o PHPSESSID ).

Solo un modo per esportare una sessione dall'autore centrale al sottodominio è:

1. Sottodominio espone link con restrizione IP e verifica dei certificati client e server. Ciò non richiede alcuna programmazione, solo attività di configurazione del server Web (host virtuale). I browser utente e chiunque altro non potrebbero mai parlare con questa porta.
2. POST di un server centrale per link lo stato e un token casuale.
3. Ora sottodominio usa questo stesso token per il suo normale archivio di sessioni.

Non ritengo che sia ottimale, richiede meno programmazione e meno CPU di sottodominio rispetto alla progettazione. Una volta che pensi a uno stato di sessione, molte possibilità e strutture esistenti ti vengono in mente.

Sottotitoli specifici:

1. Stai proponendo di creare il tuo protocollo di autenticazione.
2. Non riesco a pensare a nessun protocollo esistente che risponda al tuo caso d'uso (errato).
3. Sì, una "cattiva risposta alla domanda sbagliata" suppongo.
4. Ogni richiesta HTTP all'interno della webapp sottodominio dove l'utente sta lavorando richiede qualche autenticazione. Non solo la richiesta HTTP esterna iniziale, ma anche quella interna. Nulla qui causerebbe l'aggiornamento del timestamp / sig quando l'utente sta facendo il suo normale lavoro. Dopo alcuni minuti, l'utente perde il proprio stato nella webapp di un sottodominio, indipendentemente dal fatto che l'utente sia attivo o meno. Stanno perdendo le loro variabili / oggetti di sessione lato server. Se risolvi questo problema e passa il loro token di sessione tramite il server di autenticazione centrale, annulla tutte le altre idee; in primo luogo non hai bisogno della tua firma e dei calcoli delle tue chiavi pubbliche / private.

Una cosa che posso pensare che possa essere problematica (se l'utente sta postando per il sottodominio) è che non si firma il sottodominio a cui l'utente sta tentando di connettersi. Lasciatemi provare a dare un esempio del problema:

Diciamo che ho credenziali (valide) per foo.example.com . Invio (foo, username, password) a example.com/login e ottengo indietro (sig=signed(id, timestamp)) . Ora I POST a bar.example.com/login con (id, timestamp, sig) . bar.example.com/login guarderà sig , verifica che timestamp corrisponda ai dati firmati e quindi accedi al id firmato. Ora sono entrato in bar.example.com . Oops.

Quindi direi che non solo l'utente non deve mai vedere il sig , ma dare all'utente il sig è in realtà un problema di sicurezza. Se rinvii sig all'utente, devi eseguire sig=signed(id, timestamp, subdomain) e il login del sottodominio deve verificare che si tratti del sottodominio firmato.

Sembra che l'invio di utente, pass e sottodominio sia l'unica autenticazione che stai facendo. Pubblicare negli altri domini non mi sembra affatto sicuro. L'ho fatto in vari scenari e per me la convalida di utente e password, indipendentemente da come è fatto, è il servizio di "autenticazione". Se si desidera separare gli utenti in sottodomini diversi, perché non utilizzare la funzionalità di proxy inverso di essenzialmente un singolo punto di ingresso. E questo può anche funzionare come bilanciamento del carico. Sono sicuro al 99% circa che è possibile raggiungere i propri obiettivi utilizzando un server proxy inverso e farlo in modo molto sicuro. L'ho fatto per lo stato della Carolina del Nord per uno degli enti governativi.