Accesso multi sottodominio per contenuto, sicurezza di primavera per main

5

Illustrazione: mainsite.com e contentsite.com sono entrambi sviluppati per la stessa compagnia da due team. avremo login etc su mainsite.com contentite.com avrà alcuni contenuti che non sono disponibili per gli utenti che non hanno registrato. Ma il login sarà tramite mainsite.com Qual è il modo migliore per implementarlo? Alcuni utenti potrebbero trovarsi su http, vogliamo che vengano reindirizzati sulla pagina http in cui si trovavano, se facevano clic su login. Oltre a questo abbiamo bisogno di contentite.com per sapere che un utente ha effettuato l'accesso e quale id è.

Ci sarà un lavoro separato sul registro e sul profilo che condivide le informazioni da mainsite a contentite.com

Quindi la domanda è: il nome utente crittografato è sufficiente (dopo aver effettuato l'accesso per indicare al sito di contenuti che l'utente ha effettuato l'accesso? aggiungere sale casuale in modo che non possa essere falsificato?) 2. hai bisogno di un webservice in modo che il contenuto possa controllare il login?

Stiamo valutando:

  1. Reindirizzamento all'accesso, quindi tocchiamo il secondo sito e permettiamo di inserire i cookie http e https. È questo che fa google (ma solo https) per youtube e altri siti di google? O una combinazione di domini di servizi Web per domini in background? Abbiamo bisogno di chiamate API per fermare l'uomo nel mezzo o è sufficiente l'SSL iniziale? Infine, vogliamo consentire agli utenti di utilizzare la maggior parte del sito Web in http o https oltre alle pagine di checkout, di accesso e di profilo.
  2. javascript add on per il dominio del contenuto, con il nome utente crittografato AES insieme ad alcuni hash. Quindi nessun reindirizzamento ma ogni volta che aggiungiamo il tag del contenuto passiamo l'utente autenticato o l'utente anonimo non ancora connesso
  3. oauth o auth0.com o altro schema, non sono sicuro se abbiamo bisogno di questo dato che stiamo già usando un impl di sicurezza di prim'ordine costruito da un grande co e vogliamo solo condividere il nostro id utente di login con un altro dominio che è il nostro

Ho esaminato alcune domande sulla stessa cosa come questa domanda sul nodo js ma non sembravano per adattarsi esattamente. C'è uno standard che ci è mancato?

Usiamo la sicurezza di primavera per il negozio principale. Il sito di contenuto non avrà una base dati, ma condivideremo alcune informazioni sul profilo tramite canali non web separati (nelle iscrizioni e nelle chiamate api di modifica del profilo).

Per accedere al sito Web del negozio sono disponibili pagine SSL che ti reindirizzano alla pagina originale (http o https).

    
posta tgkprog 27.07.2014 - 14:12
fonte

2 risposte

5

Penso che OAuth sia la soluzione migliore; specificamente OAuth2. Potrebbe essere un po 'eccessivo, ma fa quello che vuoi.

OAuth

OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner.

Che cosa significa? Hai un'applicazione client, contentsite.com, che vorresti dare accesso sicuro a tramite mainite.com. La registrazione dell'utente dovrebbe già essere implementata. Il sito contentite.com reindirizzerà a mainsite.com per il login e fornirà un token di accesso a mainsite.com a contentsite.com. Se l'utente si disconnette, il token non è più valido e, se utilizzato, dovrebbe reindirizzare nuovamente al login.

il sito contentite.com si registra su mainsite.com come applicazione e riceve un valore segreto e un ID cliente. L'ID client viene utilizzato quando si richiede un token. I token di accesso vengono utilizzati per qualsiasi altro accesso alle risorse una volta concesso. Panoramica ad alto livello di OAuth2 .

Per realizzare tutto questo è necessario implementare un provider OAuth sul tuo sito principale. Ecco un passo alla volta con un codice server scritto in Python usando Flask. L'implementazione lato client è piuttosto semplice. Dato l'ID client e il segreto, fai una richiesta al tuo fornitore OAuth per un token. Ecco un link a una bella piccola libreria Python , puoi dichiarare i reindirizzamenti proprio sul lato client. Dovresti semplicemente sostituire i link specifici di Google con i link specifici del tuo sito.

Come ho detto potrebbe essere un po 'eccessivo, ma fa esattamente quello che vuoi. Se vuoi che gli utenti siano in grado di accedere con cose come Facebook o Google+ o qualsiasi altra cosa, allora la funzionalità è lì. Inoltre, lo standard OAuth2 richiede l'uso di SSL / TLS per le sue richieste. Sempre un vantaggio.

Sicurezza Spring

Spring Security OAuth - Pagina principale
Spring Security OAuth2 - Guida per lo sviluppatore
Spring Security OAuth - Github

Esempi concettuali per OAuth (non Spring Security)

Come implementare l'accesso sicuro tramite OAuth - Questo collegamento si concentra sull'utilizzo di Facebook, Google+, ecc. Come base per la registrazione / login. Se volevi supportarlo.

Alcune note su implementare un server OAuth2 Node , da Papers.

Ecco una buona risorsa per librerie OAuth per lingue diverse, lato server e client.

RFC OAuth2 - Se ti piace leggere gli RFC

    
risposta data 22.08.2014 - 14:36
fonte
1

Se disponi di una configurazione HTTPS per le tue pagine di accesso, non c'è quasi un valido motivo per non mantenerlo su tutto il sito web. Se un utente visita una pagina non crittografata con un ID / token di sessione specifico, cosa impedisce a uno spoofing avversario di rubare quel token e quindi visitare anche il sito web?

E non si tratta solo del fatto che il token sia osservato, ma anche del fatto che non puoi dire quale delle due richieste HTTP con lo stesso token è "legittima", mentre puoi dire che quando hai una crittografia esistente connessione associata a un token di sessione non ti aspetti che un'altra sessione SSL venga avviata da qualche altra parte e l'altra estremità di quella sessione invii su un token di sessione esistente.

    
risposta data 22.08.2014 - 13:29
fonte

Leggi altre domande sui tag