Propagazione dell'identità tramite il bus di servizio di Azure

3

Al momento disponiamo di una piattaforma con un'architettura SOA in cui l'identità dell'utente viene propagata dall'applicazione web tramite servizi di livello intermedio (REST e SOAP) fino a quando non si interroga effettivamente il livello di archiviazione dei dati.

Usiamo l'identità dell'utente per applicare il controllo di accesso a livello di entità. L'identità dell'utente viene comunicata tra i servizi associando i token di sicurezza alle chiamate di servizio (SAML / JWT).

Uno dei nostri clienti desidera utilizzare una Event Driven Architecture per creare un prodotto sulla nostra piattaforma anziché modello di richiesta / risposta più tradizionale. Vogliono utilizzare il Azure Service Bus Code e argomenti per ottenere una scalabilità più elevata.

Mi chiedevo come in questa architettura potessimo propagare l'identità dell'utente ai consumatori dei messaggi / eventi memorizzati sul bus di servizio.

PER ESEMPIO:

Supponiamo che l'utente crei una nuova attività nell'applicazione Web front-end. Invece di chiamare il servizio Attività (che invia l'identità dell'utente) e attendere la risposta, l'applicazione memorizza l'evento di creazione dell'attività nella coda e delega la creazione effettiva dell'attività a un lavoratore in background iscritto a questo tipo di messaggio.

Tuttavia, per determinare se l'utente che ha avviato la creazione dell'attività è autorizzato a creare un'attività, il servizio attività (un operatore in background) deve chiamare il livello entità nel contesto dell'utente.

Potrei memorizzare il token di sicurezza insieme al carico utile per la creazione dell'attività, ma dato il disaccoppiamento temporale tra produttore e consumatore, questo token potrebbe essere scaduto dal momento in cui è usato per chiamare nel livello entità.

Esistono schemi ben definiti per risolvere questo problema? Mi rendo conto che posso spostare il controllo degli accessi nell'applicazione web, ma dato che abbiamo creato una piattaforma su cui gli altri possono creare applicazioni, non voglio necessariamente fidarmi di quelle applicazioni per far rispettare i requisiti di sicurezza. Questo è il motivo principale per cui abbiamo creato il controllo accessi nel livello entità.

Tutti i consumatori di eventi del bus di servizio fanno sempre parte di un sottosistema fidato, o ci sono modi per risolverlo elegantemente?

    
posta MvdD 24.09.2015 - 04:55
fonte

1 risposta

1

Ci sono comunemente due ruoli di identità in gioco quando si usa il middleware per i messaggi di routing. Un ruolo di identità riguarda la relazione tra mittenti / destinatari e il middleware, l'altro riguarda la relazione end-to-end tra il produttore del messaggio e il consumatore finale del messaggio.

L'identità utilizzata in questi due ruoli può essere la stessa, ma può anche essere diversa e spesso lo è.

Per Service Bus, abbiamo scelto un modello basato su token per il controllo degli accessi che consente un approccio di sottosistema affidabile e identità concrete da utilizzare per il rapporto mittente / destinatario con il middlware con lo stesso modello. Il token di accesso condiviso può essere generato direttamente dal client quando è in possesso della chiave condivisa. Ecco come i nostri fornitori di token funzionano con stringhe di connessione. Puoi anche generare quei token esternamente in un semplice STS (utilizzando il provider di token o link ) e li scambia con la prova dell'identità dell'utente finale e passa il token al provider di token di accesso condiviso.

Per la relazione end-to-end tra produttore e consumatore, lasciamo la porta aperta per tutto ciò che è appropriato per il caso d'uso. Restiamo fuori e non interpretiamo il corpo del payload e quindi permettiamo che sia firmato e criptato. È possibile eseguire il flusso di token e suggerimenti chiave nelle proprietà del messaggio. È possibile trasferire token di lunga durata (inclusi i JWT da Azure Active Directory) in proprietà o payload oppure utilizzare certificati X.509 per autenticare e proteggere il payload end-to-end. JWE è un nuovo standard per la sicurezza a livello di payload link

    
risposta data 24.09.2015 - 06:47
fonte