Autenticazione tra più sistemi / piattaforme all'interno dello stesso contesto applicativo web

• Genera un token di sessione al login.
• Archivia quel token di sessione nel database.
• Verifica i token di sessione validi durante l'autenticazione.

Praticamente quello che hai. Pensa solo se vuoi avere più di una sessione valida in una volta e come farai le sessioni in scadenza.

MODIFICA per il thread di commento pazzo di seguito

Mentre si possono fornire token al client che sono verificati dal secondo server senza comunicare con il 1 ° server, è brutto e richiede molto lavoro. Tale scenario non consente di invalidare le sessioni a meno che il client non si occupi di esso. Richiede anche una certa finestra temporale quando vengono passati token, timestamp dei token, tracciamento dei token dal 2 ° sistema, firma o HMAC nel passaggio dei token, ecc. A meno che questi due sistemi non possano vedersi su Internet, basta evitare quel casino completamente.

Capisco che entrambi i sistemi possono accedere allo stesso database, ma se per qualche ragione non possono farlo, anche l'API esposta al secondo sistema che può verificare da remoto sarebbe appropriata (secret.page?checkUser=token. .. o simili).

Senza SSL, non c'è nulla che tu possa fare per prevenire il dirottamento di sessione con gli attacchi Firesheep / MITM.

La mia raccomandazione è una singola app Web utilizzata per l'autenticazione dell'utente principale.

Nota: A causa della natura dei cookie, questo metodo funziona solo se le applicazioni web condividono un dominio comune. (ad esempio appone.example.com e apptwo.example.com)
openid fa qualcosa di simile ma ignora il problema dei cookie, potresti voler dare un'occhiata a intot hat.

Come funzionerebbe.

1. L'utente punta il suo browser verso App A. App A controlla cookie / sessione / qualunque cosa sia valida.
   1. Prima controlla le proprie informazioni su sessione / cookie.
   2. Se non riesce a trovare il proprio cookie, cerca il cookie "trasferimento" di Auth App.
      1. Se viene trovato, crea una nuova sessione per questa app. L'utente ha appena effettuato l'accesso.
2. Quando trova che questo non è valido o mancante, inoltra la pagina verso l'App di autenticazione.
3. L'app di autenticazione verifica una sessione valida alla sua fine.
   1. Quando viene rilevato questo mancante, viene visualizzata una schermata di accesso, ecc.
4. Una volta che ha una sessione valida, l'App Auth imposta uno specifico "trasferimento" cookie per quell'app e reindirizza la persona all'App A.

Dovresti inserire informazioni extra in questo cookie di trasferimento come -

1. nome utente
2. AuthTime
3. indirizzo IP.
4. Numero casuale.

Vedi il seguente per un esempio. link

Questo sarà per lo più apparentemente dal punto di vista dell'utente. Ad esempio.

1. L'utente punta il browser verso l'app A.
2. L'app A fa ballare l'autenticazione con l'app di autenticazione. (richiede all'utente di accedere, ecc.)
3. L'utente fa clic su un collegamento che inoltra all'app B.
4. L'app B fa il ballo di autenticazione con l'app di autenticazione. (Questa volta, l'app di Auth ha già un cookie per sé.)
   1. App B inoltra all'app di autenticazione
   2. L'app di autenticazione trova i cookie e subito crea i cookie di trasferimento e inoltra all'App B
   3. L'utente non si accorge nemmeno di questo e si trova immediatamente all'App B.

Quattro opzioni, una prima con il massimo costo (denaro e prestazioni entrambe) e la terza più economica

1. Distribuire soluzioni come Siteminder, Novell, Tivoli ecc.

2. Mantenimento dello stato della sessione nel DB. Per fare questo. Il problema con questo approccio è che sarebbe difficile tracciare i logout, la scadenza della sessione e la diffusione di questa informazione tra le due applicazioni. Come interrogare il DB prima di ogni richiesta sarebbe molto costoso

3. Utilizzo di una terza applicazione solo per gestire gli stati di sessione. Questa applicazione non è esposta all'utente finale limitato solo all'interno della rete con accesso solo alle due applicazioni Memorizza gli stati per tutti gli utenti nel contesto dell'applicazione e le due applicazioni inviano una richiesta a questa applicazione

   On login events On logout events On session expiry events before processing any request to check session validity

4. Utilizzo di un cookie (presupponendo che entrambe le applicazioni condividano lo stesso dominio padre)

   Create a cookie which contains username + salt/ecret key and this encrypted Secret key and the encryption keys are with both applications Any request from user will carry this cookie ( Cookie path set to /) So if the cookie contains a username, other application trusts user is logged in on other application