Progettazione servizio SOA/Autenticazione

Question

Sono piuttosto nuovo di SOA e quindi di sperimentare.

Attualmente, la parte che crea il problema più grande per me è l'autenticazione, il mio attuale pensiero su di esso prevede:

Il client invia un qualche tipo di messaggio di autenticazione per il servizio di autenticazione/utente, questo servizio interroga il db e se l'utente viene trovato e la password è valida, risponderà con un id di sessione, questo ID verrà utilizzato in tutte le ulteriori richieste di questo client.

Questo mi sembra piuttosto ok ma non so come gestire le richieste ad altri servizi, ho pensato a tre approcci diversi.

1. Ogni servizio chiede il servizio di autenticazione se la sessione è valida e, in caso affermativo, quali ruoli che l'utente si trova. Il servizio di autenticazione appare nel db e risponde di conseguenza.

2. Il servizio di autenticazione mantiene tutte le informazioni di sessione in ram e risponde senza il db roundtrip alle richieste.

3. Il servizio di autenticazione invia un messaggio autorizzato a un esb, l'esb inoltra questo messaggio autorizzato a ogni servizio e questi servizi lo memorizzano nella cache. Non sarebbero necessarie ulteriori richieste al servizio di autenticazione. Se l'utente si disconnette oi suoi ruoli cambiano, un altro messaggio verrebbe inviato e elaborato da tutti i servizi.

Penso che il primo approccio crea troppo stress sul servizio di autenticazione/db ma richiede il minimo sforzo per implementare.

Il secondo è ancora molto facile da implementare ma lo stress sul servizio di autenticazione rimane quasi lo stesso.

Il terzo è un po 'più complicato da implementare, ma avrebbe ridotto il tempo di risposta in quanto non si verifica alcun intervento sul servizio di autenticazione. Però, se ci sono troppe informazioni sulla sessione, questo approccio fallirebbe e la scalabilità non è quasi mai data.

Answer 1

L'approccio migliore dovrebbe essere come questo se tutti i servizi sono interni,

1. Il servizio di autenticazione emette un token del client del servizio.
2. Il client di servizio include il token nel messaggio SOA incluso in WS-Security o qualcosa di simile.
3. Il servizio deve convalidare il token con il servizio di autenticazione prima di fornire il servizio.

Per servizi esterni, suggerisco di guardare soluzioni federate come SAML.

Answer 2

Non fare l'ottimizzazione prematura. L'opzione n. 3 che tu riconosci che sarà più complicato da implementare non è necessario. Scegli l'opzione no. 2 se è quello che puoi implementare velocemente. Puoi profilare in un secondo momento e cambiarlo, ma scommetto che non avrai un collo di bottiglia quando vai con l'opzione 2.