Die umfangreichen Security-Funktionen, die openUTM bietet, stehen Ihnen auch dann zur Verfügung, wenn bei verteilter Verarbeitung mehrere UTM-Anwendungen über Server-Server-Kommunikation zusammenarbeiten.
Zugangsschutz durch logische Anschlusspunkte
UTM-Anwendungen können nur dann zusammenarbeiten, wenn in jeder Anwendung für die jeweils (aus Sicht dieser Anwendung) fernen Partner-Anwendungen logische Anschlusspunkte definiert sind. Diese Anschlusspunkte heißen (OSI-)LPAP-Partner (siehe auch "Zugangskontrolle (Identifizierung und Authentisierung)"). Zusätzlich können Sie bei verteilter Verarbeitung über OSI TP das UTM-Benutzerkonzept auch Anwendungs-übergreifend nutzen (siehe "Zugangskontrolle (Identifizierung und Authentisierung)").
Zugriffsschutz bei verteilter Verarbeitung
Auch bei verteilter Verarbeitung steht Ihnen das Lock-/Keycode-Konzept und das Access-List-Konzept von openUTM zur Verfügung. Die Schutzmaßnahmen werden bei der Generierung der Anwendungen festgelegt.
Schutzmaßnahmen in der Auftraggeber-Anwendung:
Bei der Generierung einer Anwendung legen Sie zunächst generell fest, welche Services einer fernen Partner-Anwendung aufrufbar sein sollen: Für jeden fernen Service, der genutzt werden soll, vereinbaren Sie einen lokalen Transaktionscode (LTAC). Der Zugriff auf ferne Services, für die keine LTACs vereinbart sind, bleibt der Anwendung grundsätzlich verwehrt.
Um den Zugriffsschutz weiter zu differenzieren, können Sie die einzelnen LTACs mit Lockcodes bzw. mit Access-Lists versehen. Ein Service der lokalen Anwendung kann nur dann einen fernen Service anfordern, wenn der Benutzer, der den lokalen Service gestartet hat, über entsprechende Keycodes verfügt.
Schutzmaßnahmen in der Partner-Server-Anwendung:
In der Partner-Server-Anwendung wird der Auftraggeber-Anwendung ein Keyset zugeordnet. Nur wenn dieses Keyset einen Keycode enthält, der zum Lockcode bzw. der Access-List des angeforderten Services passt, wird der von der Auftraggeber-Anwendung angeforderte Vorgang gestartet.
Damit auf einen fernen Service zugegriffen werden kann, muss also in der lokalen Anwendung der Lockcode bzw. die Access-List des LTACs überwunden werden.
Außerdem muss das Keyset, das die Partner-Server-Anwendung allen von der Auftraggeber-Anwendung eingehenden Anforderungen zuordnet, einen Keycode enthalten, der zu dem in der Partner-Server-Anwendung definierten Lockcode bzw. zu der Access-List des Services passt.
Beispiel: Lock-/Keycode-Konzept bei verteilter Verarbeitung
Bild 35: Zugriffsschutz mit dem Lock-/Keycode-Konzept bei verteilter Verarbeitung
In dem in Bild 35 gezeigten Beispiel ist eine Server-Server-Kommunikation zwischen Anwendung A und Anwendung B grundsätzlich möglich, da in jeder Anwendung für die jeweils ferne Anwendung ein LPAP-Partner generiert ist. In der Anwendung A sind LTACs nur für die fernen Services SB2 und SB3 generiert. Der Service SB1 kann also von Anwendung A aus auf keinen Fall genutzt werden. Ein Benutzer, der sich an Anwendung A unter der Benutzerkennung „UA1“ anmeldet, verfügt über den Keycode 1 und kann damit in der Anwendung A den Service SA1 nutzen.
Da der Benutzer auch passende Keycodes für die beiden LTACs besitzt, kann Service SA1 über diese LTACs die Dienste der fernen Services SB2 und SB3 anfordern. Auch in dem Keyset, das Anwendung B allen von Anwendung A eingehenden Anforderungen zuordnet, sind passende Keycodes für die Services SB2 und SB3 enthalten. Somit sind sowohl in der Konfiguration von Anwendung A als auch in der Konfiguration von Anwendung B alle Voraussetzungen erfüllt: Der unter der Benutzerkennung UA1 in der Anwendung A gestartete Service SA1 darf auf die Services SB2 und SB3 der Anwendung B zugreifen.
Beispiel: Access-List-Konzept bei Verteilter Verarbeitung
Bild 36: Zugriffsschutz mit dem Access-List-Konzept bei verteilter Verarbeitung
In dem in Bild 36 gezeigten Beispiel ist eine Server-Server-Kommunikation zwischen Anwendung A und Anwendung B grundsätzlich möglich, da in jeder Anwendung für die jeweils ferne Anwendung ein LPAP-Partner generiert ist. In der Anwendung A sind LTACs nur für die fernen Services SB2 und SB3 generiert. Der Service SB1 kann also von Anwendung A aus nicht genutzt werden.
Ein Benutzer, der sich an Anwendung A unter der Benutzerkennung „UA1“ anmeldet, verfügt über die Rolle „1“. Damit kann er in der Anwendung A den Service SA1 nutzen. Da die Rolle „1“ auch den Zugriff auf die beiden LTACs erlaubt, kann Service SA1 über diese LTACs die Dienste der fernen Services SB2 und SB3 anfordern. In der Anwendung B besitzt das LPAP für die Anwendung A den Key „6“, der dazu berechtigt, die Services SB2 und SB3 aufzurufen.
Daher sind alle Voraussetzungen erfüllt, damit der unter der Benutzerkennung UA1 in der Anwendung A gestartete Service SA1 auf die Services SB2 und SB3 der Anwendung B zugreifen darf. Entsprechendes gilt, wenn der User UB1 über den Service SB1 auf den Service SA2 in Anwendung A zugreifen möchte.