Zugriffskontrolle bei verteilter Verarbeitung

Auch bei verteilter Verarbeitung können Sie die Mechanismen von openUTM zur Zugriffskontrolle nutzen. Die Schutzmaßnahmen werden bei der Generierung der Anwendungen festgelegt. Dabei wird zwischen Auftraggeber- und Auftragnehmer-Service (=Vorgang) unterschieden.

Schutzmaßnahmen für Auftraggeber-Services

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 (LTAC-Anweisung). 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 (siehe Abschnitt "Lock-/Keycode-Konzept") oder mit Access-Lists (siehe Abschnitt "Access-List-Konzept") versehen. Ein Service der lokalen Anwendung kann einen fernen Service nur dann adressieren, wenn der Service unter einer Benutzerkennung (KCBENID) und von einem Client (KCLOGTER) aus gestartet wurde, die die entsprechenden Zugriffsrechte haben.

LTAC-Anweisung im Abschnitt "LTAC - Transaktionscode für Partner-Anwendung definieren" Mit den folgenden Operanden wird festgelegt, welcher Service einer fernen Partner-Anwendung aufrufbar sein soll, und welche Zugriffsrechte auf den LTAC bestehen. Die Operanden ACCESS-LIST und LOCK schließen sich aus.

• ltacname

  Name eines lokalen TACs (LTAC) für das ferne Service-Programm.

• ACCESS-LIST=

  Name einer Access-List. Um das ferne Service-Programm starten zu dürfen, muss ein Benutzer der lokalen UTM-Anwendung in seinem Keyset mindestens eine zur Access-List passende Rolle zugewiesen bekommen haben (definiert in der USER-Anweisung).
  Die Access-List muss mit einer KSET-Anweisung definiert werden.

• LOCK=

  Definition des Lockcodes für den Zugriff auf das ferne Service-Programm. Ein Service der lokalen Anwendung kann diesen fernen Service nur dann adressieren, wenn der lokale Service unter einer Benutzerkennung (KCBENID) und von einem Client (KCLOGTER) aus gestartet wurde, die die entsprechenden Zugriffsrechte haben.
  ACCESS-LIST und LOCK können nicht gleichzeitig angegeben werden.

Geben Sie weder ACCESS-LIST noch LOCK an, dann ist der LTAC nicht geschützt und jeder Benutzer der lokalen UTM-Anwendung kann das ferne Service-Programm adressieren.

Schutzmaßnahmen für Auftragnehmer-Services

Auftragnehmer-Services werden geschützt, indem Sie dem logischen Anschlusspunkt einer Partner-Anwendung (LPAP bzw. OSI-LPAP) ein Keyset zuordnen. Nur wenn dieses Keyset einen Keycode bzw. einen Zugangscode enthält, der zum Lockcode bzw. zur Access-List des angeforderten Services passt, wird der von der Partner-Anwendung angeforderte Vorgang gestartet.

Damit auf einen fernen Service zugegriffen werden kann, muss der gerufene Service mit einem TAC generiert sein und es müssen folgende Bedingungen erfüllt sein:

• LU6.1-Verbindungen:

  Das in LPAP ...,KSET= definierte Keyset für den Partner muss einen Keycode enthalten, der zu LOCK= bzw. ACCESS-LIST= des TAC passt.

• OSI TP-Verbindungen:

  • Meldet sich der Partner ohne Benutzerkennung an, dann muss sowohl das in OSI-LPAP ... ,KSET= als auch das in OSI-LPAP ...,ASS-KSET= definierte Keyset einen Schlüssel enthalten, der zu LOCK= bzw. ACCESS-LIST= des TAC passt.

    Die Zugriffsrechte ergeben sich aus der Schnittmenge der Keysets von KSET= und ASS-KSET=. Daher sollte KSET= immer eine Obermenge von ASS-KSET= sein. Durch geeignete Beschränkung des mit OSI-LPAP ...,ASS-KSET= definierten Keyset können Sie erreichen, dass bestimmte TACs nur aufgerufen werden
    können, wenn der Partner eine echte Benutzerkennung angibt.

  • Meldet sich der Partner mit einer echten Benutzerkennung an, dann müssen das Keyset dieser Benutzerkennung und das in OSI-LPAP ...,KSET= definierte Keyset einen Schlüssel enthalten, der zu LOCK= bzw. ACCESS-LIST= des TAC passt.

  Dies gilt auch für eine Client-Server-Kopplung mit OpenCPIC.

Für ausführliche Informationen zur Zugriffskontrolle bei verteilter Verarbeitung siehe openUTM-Handbuch „Konzepte und Funktionen“.