Wo werden die Benutzeranmeldeinformationen in einer Unternehmensanwendung (EAI) gespeichert?

Normalerweise ist es die Anwendung, die Anmeldeinformationen für die Datenbank, SAP usw. erhält. Einzelne Benutzer würden Anmeldeinformationen in einem LDAP oder einer Datenbank gespeichert haben; Authentifizierung und Autorisierung würden von der Anwendung, dem EAI-Server oder einer Appliance wie SiteMinder als übergreifendes Problem behandelt.

Eingehende Anfragen werden abgefangen und auf Berechtigungstokens überprüft. Wenn das Token nicht angezeigt wird, überprüfen Sie die Authentifizierung und Autorisierung. Wenn dies zulässig ist, erstellen Sie das Autorisierungstoken und cachen Sie es.

Dies ist das übliche Szenario für Webanwendungen. Für eine Ereignisbenachrichtigung wie Ihre ist es komplizierter. Sie müssen nach Autorisierung suchen, wenn der Benutzer sich anmeldet. Sie sollten sie sofort benachrichtigen, wenn der Benutzer nicht autorisiert ist, da Sie die Anmeldeinformationen nicht jedes Mal überprüfen müssen, wenn Sie veröffentlichen. Es muss eine Verbindung zwischen einem Benutzer, einem abonnierten Ereignis und dem Autorisierungsnachweis bestehen.

Ich sehe nur ein Problem.

Sie können Ereignisse an einen nicht autorisierten Benutzer senden, wenn sie ein Ereignis abonnieren, herausfinden, dass sie autorisiert sind, die erste Übertragung erhalten und dann aus irgendeinem Grund nicht autorisiert werden. Dies bedeutet, dass Sie die Anmeldedaten jedes Mal überprüfen müssen, wenn Sie an Abonnenten senden. Dies könnte beschwerlich werden und Ihre App verlangsamen.

Sehen Sie sich Standards wie SAML an, um zu sehen, ob es Ihnen helfen kann.

Das Caching-Problem hängt vom Vergleich zwischen der Zeit zwischen Ereignissen und zwischen Autorisierungsänderungen ab. Wenn die Zeit zwischen den Ereignissen lang ist verglichen mit Autorisierungsänderungen, müssen Sie jedes Mal überprüfen, weil Sie nicht wissen können, ob die Autorisierung seit dem letzten Ereignis aufgehoben wurde.

Das Muster, das ich am häufigsten gesehen habe, besteht darin, dass die Autorisierung eher im Abonnement als im Backend erfolgt. Die Themenhierarchie spiegelt das Sicherheitsmodell der Back-End-Anwendung wider. Verfügt das Backend über Funktionen zum Abfragen von Produce, Deli und Grocery, gibt es Themenknoten mit denselben Klassifizierungen. Benutzer, die im Backend-System für Lebensmittelgeschäft autorisiert sind, sind auch zum Thema Lebensmittelgeschäft berechtigt. Die Berechtigungen im Backend-System können periodisch exportiert werden (häufig ist dies nachts) und in Berechtigungseinstellungen am Pub / Sub-Broker konvertiert. In einer Implementierung, die ich am Backend-System bearbeitete, würde ich Autorisierungsänderungen für den Pub / Subbroker in einem sicheren Verwaltungsthema veröffentlichen, so dass die Abonnentenberechtigungen in nahezu Echtzeit aktualisiert würden.

Die Weitergabe von Anmeldeinformationen an das Quellsystem klingt auf den ersten Blick sicher, bei genauerer Betrachtung treten jedoch einige Probleme auf. Erstens, wie planen Sie, dies zu skalieren? Ich habe noch nie ein erfolgreiches Ereignisbenachrichtigungssystem gesehen, das nicht stark wiederverwendet wurde. Jedes Backend-System wird unterschiedliche Anforderungen für die Authentifizierung haben, normalerweise unterschiedliche Anmeldeinformationen, unterschiedliche Gültigkeits- und Caching-Anforderungen usw. Das Erstellen des Systems zum Weiterleiten von Anmeldeinformationen an mehrere Back-End-Anwendungen ist eine Sache. Es für 10 oder 20 zu tun ist ein Albtraum.

Wenn Sie davon ausgehen, dass Sie die oben genannten Probleme behoben haben, haben Sie nun Benutzeranmeldeinformationen für die Hälfte der Backend-Unternehmenssysteme an einem Ort zwischengespeichert. Wenn dieses eine zentrale System kompromittiert wird, sind es auch alle Back-End-Systeme, mit denen es kommuniziert. Dieses zentrale System wurde gerade zum kritischsten Sicherheitsschwerpunkt im Unternehmen. Ernsthafte Sicherheits-Fu benötigt, um dieses Problem anzugehen, ist teuer.

Ja, es ist ein Schmerz in den Hintern, damit der Themenbaum und die Berechtigungen des Pub / Sub Brokers das Sicherheitsmodell der Backend-Anwendungen widerspiegeln. Aber am Ende ist es viel einfacher (und weniger kostspielig), einen zentralen Broker-Service zu entwerfen, der sicher genug ist, alle Anmeldeinformationen zu speichern und sie über mehrere Back-End-Systeme zu validieren, ohne den Broker oder die Quellsysteme zu verwerfen dazu.

Im Setup, das Sie in der Frage beschreiben, müssen Sie eine Möglichkeit schaffen, die Nachrichtenwarteschlangen zu löschen. Was passiert zum Beispiel, wenn ein Teilnehmer Probleme hat und keine Nachrichten mehr empfängt, oder was passiert, wenn versehentlich einige schlecht formatierte Nachrichten in die Abonnementthemen gelangen und diese Nachrichten dazu führen, dass der Client die Nachrichten für einen Absturz erhält. Aus diesem Grund muss Ihr System einige Verwaltungsfunktionen haben, um Nachrichten zu löschen. Sie können diese Administratorfunktionalität erneut verwenden, um eine gelöschte Benutzernachricht vom externen System an die ENS abzusetzen. Diese vom Benutzer gelöschte Nachricht würde dazu führen, dass die Benachrichtigungswarteschlange der Benutzer geleert wird und ihre Subskription ungültig wird.

Eine andere Sache, die Sie verwenden können, um den Fall auf den externen Systemen zu behandeln, die den Benutzer löschen, ist, dass Benachrichtigungsnachrichten von externen Systemen Ablaufzeiten auf ihnen haben. Zum Beispiel könnte eine SAP-Benachrichtigung für 2 Stunden nach der Erstellungszeit gültig sein. Wenn der Benutzer die Nachricht nicht innerhalb von 2 Stunden erhält, wird die Nachricht gelöscht. Wenn Sie Nachrichtenablauf mit Benachrichtigungsnachrichten von SAP kombinieren, dass ein Benutzer nicht mehr gültig ist, können Sie wissen, dass es ein Zeitlimit gibt, während dem ein Benutzer ungültig wird.

Ich denke, wenn Sie mehr Kontext über die Technologien bereitstellen, mit denen Sie ENS implementieren, können wir Ihnen möglicherweise konkretere Antworten geben.

LDAP ist eine bessere Option für die Speicherung, es sicher und schnell und portabel auch

* EDIT: Portable im Sinne des Zugriffs auf Ihre Unternehmens-App.