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

9

Hintergrund / Kontext

Wir entwickeln einen Ereignisbenachrichtigungsdienst . Die Anwendung auf hohem Niveau sieht wie folgt aus:

Unser entwickelter Bereich beinhaltet Widget und die ENS.

" ENS " dient als zentrale Sammelstelle für bestimmte Arten von Ereignissen, die für Nutzer von Interesse sind. Jeder Benutzer, der wissen möchte, wann solche Ereignistypen auftreten, wird bei ENS registriert. die Ereignisse in der Reihenfolge identifiziert und Benachrichtigungen mit Abonnements abgleicht.

Der Benutzer, der teilnehmen möchte, sollte ein gültiger Benutzer der integrierten Anwendung sein (db, sap system usw.)

Die Reihenfolge der Ereignisse:

Jetzt ist meine Frage:

Was ist die beste Praxis beim Speichern der Benutzer db, sap etc Anmeldeinformationen?

BEARBEITEN Wie oft sollte der Benutzer authentifiziert werden? Sollte es immer sein, wenn die Nachrichten zugestellt werden? (Wie @duffymo erwähnt, wenn ich diese Strategie verwende, wird es das Quellsystem beeinflussen)

Zusätzliche Informationen: ENS sind die Web-Services.

ENS fragt das SAP (und andere Anwendungen) ab, und hier wird das Problem immer komplexer. In SAP gibt es eine Berechtigung auf Datenebene. Daher dürfen nicht alle Benutzer alle Ereignisse / Daten sehen.

Wenn das SAP die Daten gepushed hat, zusammen mit den Benutzerinformationen, die autorisiert wurden zu sehen, dann gibt es überhaupt keine Probleme.

Fall 1: Der Scheduler wird von der ENS eingeleitet

  1. Der Benutzer abonniert ein Abonnement. Zum Zeitpunkt des Abonnements wird der Benutzer im SAP-System auf seine Berechtigung geprüft. Wenn OK, dann wird er für das Abonnement erlaubt.
  2. Der Scheduler wird zum geplanten Zeitpunkt ausgeführt.
  3. Der Scheduler identifiziert die abonnierten Benutzer.
  4. Der Scheduler verwendet die gespeicherten Anmeldeinformationen der Benutzer (die in ENS enthalten sind) zum POLL, wenn das Ereignis aufgetreten ist.
  5. Benachrichtigen Sie die Benutzer, wenn Änderungen vorgenommen wurden.

Disadvs hier:

  • Benutzeranmeldeinformationen werden irgendwo gespeichert extern - Sicherheitsteam möglicherweise nicht akzeptiere es
  • Reduntant schlägt wenn mehr als ein Benutzer ist für das gleiche Stück von abonniert Informationen

Fall 2: Der Scheduler wird vom WIDGET erkannt. Benutzer-Creds werden nur auf dem lokalen Computer des Benutzers gespeichert. Diadv:

  • Wenn das Abonnement täglich ist und wenn Das Benutzersystem / Widget ist nicht aktiv. Das Benutzer könnte die Benachrichtigungen verpassen das ist etwa am Wochenende passiert.
  • Reduntant schlägt auf den Server wenn mehr als ein Benutzer für die abonniert hat die gleiche Information.
HanuAthena 09.02.2011, 10:25
quelle

4 Antworten

3

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.

    
duffymo 09.02.2011 10:37
quelle
1

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.

    
T.Rob 17.02.2011 04:14
quelle
0

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.

    
ams 16.02.2011 20:40
quelle
0

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.

    
Badr 18.02.2011 05:47
quelle