dove memorizzare le credenziali dell'utente in un'applicazione enterprise (EAI)?

Question

Sfondo/Context

Stiamo sviluppando un Event Notification Service. L'applicazione ad alto livello è la seguente:

Il nostro ambito di sviluppo comprende widget e ENS.

"ENS" funge da punto di raccolta centrale per determinati tipi di eventi che interessano gli utenti. Qualsiasi utente che desideri sapere quando si verificano questi tipi di eventi registri con ENS, , che identifica gli eventi in ordine e abbina le notifiche con gli abbonamenti.

L'utente che vuole Iscriviti, dovrebbe essere un utente valido dell'applicazione intergrated (db, sistema SAP ecc)

La sequenza degli eventi:

Ora la mia domanda è:

Quali sono le migliori pratiche per la memorizzazione delle credenziali db, sap ecc.

MODIFICA Con quale frequenza l'utente deve essere autenticato? Dovrebbe essere ogni volta che i messaggi vengono consegnati? (Come indicato da @duffymo, se utilizzo questa strategia, influirà sul sistema sorgente)

Ulteriori informazioni: ENS sono i servizi web.

ENS esegue il polling del SAP (e di altre applicazioni) ed è qui che il problema sta diventando più complesso. In SAP esiste l'autorizzazione a livello di dati. Quindi non tutti gli utenti sono autorizzati a vedere tutti gli eventi/dati.

Se SAP ha PUSH i dati, insieme alle informazioni utente che ha autorizzato a vedere, quindi nessun problema.

Caso 1: pianificazione è iniziata dal ENS

1. utente sottoscrive un abbonamento. Al momento della sottoscrizione, l'utente viene controllato per la sua autorizzazione nel sistema SAP. Se OK, allora gli sarà consentito l'Abbonamento.
2. Lo scheduler viene eseguito all'ora pianificata.
3. Lo scheduler identifica gli utenti che sono iscritti.
4. Lo scheduler utilizza le credenziali memorizzate degli utenti (arricchite in ENS) in POLL se si verifica l'evento.
5. Notifica agli utenti se sono presenti modifiche.

Disadvs qui:

• le credenziali dell'utente vengono memorizzati da qualche parte esterno - squadra di sicurezza potrebbe non accettarlo
• Reduntant colpisce se più di un utente è sottoscritto per lo stesso pezzo di informazioni

Caso 2: Lo scheduler è denominato WIDGET. I crediti utente verranno memorizzati solo nella macchina locale dell'utente. Diadv:

• Se l'abbonamento è giornaliera, e se il sistema utente/widget di non è all'altezza. L'utente potrebbe perdere le notifiche che accadono per esempio, nei fine settimana.
• Chiamate ridondanti sul server se più di un utente è stato sottoscritto per lo stesso numero di informazioni .

Answer 1

Di solito è l'applicazione che ha le credenziali del database, SAP, ecc. I singoli utenti dovrebbero avere le credenziali memorizzate in un LDAP o in un database; l'autenticazione e l'autorizzazione sarebbero trattate come una preoccupazione trasversale dall'applicazione, dal server EAI o da un'appliance come SiteMinder.

Le richieste in entrata sarebbero intercettate e controllate per i token di autorizzazione. Se il token non viene visualizzato, verificare l'autenticazione e l'autorizzazione. Se consentito, creare il token di autorizzazione e memorizzarlo nella cache.

Questo è il solito scenario per le applicazioni Web. Per una situazione di notifica di eventi come la tua è più complicato. Dovrai controllare l'autorizzazione quando l'utente si iscrive. Dovresti avvisarli immediatamente se l'utente non è autorizzato, perché non vuoi dover controllare le credenziali ogni volta che pubblichi. Dovrà esserci un'associazione tra un utente, un evento sottoscritto e le credenziali di autorizzazione.

Vedo solo un problema.

È possibile trasmettere eventi a un utente non autorizzato se si iscrive a un evento, si accorge di essere autorizzato, riceve la prima trasmissione e quindi non è autorizzato per qualche motivo. Questo suggerisce che dovrai controllare le credenziali ogni volta che trasmetti agli abbonati. Questo potrebbe diventare oneroso e rallentare la tua app.

Dai un'occhiata a standard come SAML per vedere se può aiutarti.

Il problema di memorizzazione nella cache dipende dal confronto tra il tempo trascorso tra gli eventi e tra le modifiche di autorizzazione. Se il tempo tra gli eventi è lungo rispetto alle modifiche all'autorizzazione, è necessario verificare ogni volta, perché non si ha modo di sapere se l'autorizzazione è stata annullata dall'ultimo evento.

Answer 2

Nella configurazione descritta nella domanda, è necessario creare un modo per cancellare le code dei messaggi. Ad esempio cosa succede quando un abbonato ha problemi e smette di ricevere messaggi o cosa accade se accidentalmente alcuni messaggi formattati in modo errato vengono visualizzati negli argomenti dell'abbonamento e tali messaggi causano il blocco dei messaggi del client. Questo è il motivo per cui il tuo sistema dovrà avere alcune funzionalità di amministrazione per eliminare i messaggi.È possibile riutilizzare questa funzionalità di amministrazione per attivare un messaggio eliminato dall'utente dal sistema esterno all'ENS, questo messaggio eliminato dall'utente causerebbe la svuotamento della coda di notifica degli utenti e la loro iscrizione diventare non valida.

Un'altra cosa che è possibile utilizzare per gestire il caso sui sistemi esterni eliminando l'utente è che i messaggi di notifica provenienti da sistemi esterni hanno tempi di scadenza su di essi. Ad esempio, un messaggio di notifica SAP potrebbe essere valido per 2 ore dopo la creazione. Se l'utente non riceve il messaggio entro 2 ore, il messaggio viene eliminato. Se unisci la scadenza del messaggio con i messaggi di notifica di SAP che un utente non è più valido, puoi sapere che esiste un limite di tempo durante il quale un utente verrà invalidato.

Penso che se fornisci più contesto sulle tecnologie che utilizzi per implementare ENS, potremmo essere in grado di darti risposte più concrete.

Answer 3

Il modo in cui ho visto questo schema implementato più spesso è che l'autorizzazione si verifica all'abbonamento piuttosto che al back-end. La gerarchia degli argomenti rispecchia il modello di sicurezza dell'applicazione back-end. Se il back-end ha funzioni per indagare su Produce, Deli e Grocery, esistono nodi argomento con le stesse classificazioni. Gli utenti che sono autorizzati nel sistema di back-end di Grocery sono anche autorizzati all'argomento Grocery. Le autorizzazioni nel sistema di back-end possono essere periodicamente esportate (frequentemente questo è di notte) e convertite in impostazioni di autorizzazione sul broker pub/sub. In un'implementazione, ho lavorato sul sistema di back-end pubblicherebbe le modifiche all'autorizzazione al pub/sub broker su un argomento amministrativo sicuro in modo che le autorizzazioni degli abbonati fossero mantenute aggiornate in tempo quasi reale.

La nozione di passare le credenziali al sistema di origine sembra sicura a prima vista, ma su un'ispezione più approfondita presenta alcuni problemi. Innanzitutto, come pensi di ridimensionarlo? Non ho mai visto un sistema di notifica degli eventi di successo che non sia stato pesantemente riutilizzato. Ogni sistema di back-end avrà requisiti diversi per l'autenticazione, solitamente credenziali diverse, requisiti di validità e caching diversi, ecc. Costruire il sistema per trasferire le credenziali a un paio di applicazioni di back-end è una cosa. Farlo per 10 o 20 è un incubo.

Supponendo di aver risolto i problemi di cui sopra, ora si hanno le credenziali dell'utente memorizzate nella cache per metà dei sistemi aziendali back-end in un'unica posizione. Se questo sistema centrale viene compromesso, lo stesso vale per tutti i sistemi di back-end. Quel sistema centrale è diventato il punto focale di sicurezza più critico nell'azienda. La seria sicurezza necessaria per affrontare questo problema è costosa.

Sì, è un rompicapo rendere l'albero degli argomenti e le autorizzazioni del broker pub/sub rispecchiano il modello di sicurezza delle applicazioni di back-end. Ma alla fine è molto più semplice (e meno costoso) che progettare un servizio di broker centrale abbastanza sicuro da archiviare tutte le credenziali e anche in grado di convalidarle su diversi sistemi di back-end senza impantanarsi sul broker o sui sistemi di origine che pubblicano ad esso.

Answer 4

LDAP sarà una scelta migliore per lo stoccaggio sicuro e veloce e portatile anche

* EDIT: portatile nel senso di accesso alla vostra impresa app.