Security-Funktionen

Folgende Security-Funktionen sind in openUTM realisiert:

Zugangsschutzfunktionen

Diese Funktionen werden in openUTM durch UTM-Benutzerkennungen und Passwörter einer bestimmten Komplexitätsstufe realisiert. Die Nutzung dieser Funktionen wird bei CPI-C und XATMI wie folgt realisiert:

• Bei CPI-C gibt es die Aufrufe

  Set_Conversation_Security_Type(): Typ des Zugangsschutzes festlegen
  Set_Conversation_Security_User_ID(): UTM-Benutzerkennung angeben
  Set_Conversation_Security_Password(): Zugehöriges Passwort angeben

• zusätzlich bei UPIC

  Set_Conversation_Security_New_Password(): neues Passwort vergeben

Diese Aufrufe müssen Sie vor dem Einrichten der Conversation absetzen.

Falls die Anmeldung nicht erfolgreich war, steht nach einem Receive- oder Receive_Mapped_Data zusätzlich noch folgende Aufrufe zur Verfügung:

Extract_Secondary_Return_Code(): erweiterten Returncode abfragen

Extract_Secondary_Information(): erweiterte Information abfragen

• • An der Schnittstelle XATMI gibt es beim Aufruf tpinit() entsprechende Parameter, mit denen diese Zugangsschutzfunktionen aktiviert werden (siehe Abschnitt „tpinit- Client initialisieren“).

  Sobald das CPI-C- oder XATMI-Programm diese Aufrufe verwendet, werden implizit auch die nachfolgend geschilderten Zugriffsschutz- und Datensicherheitsfunktionen wirksam.

Zugriffsschutzfunktionen

Damit bestimmte Services der UTM-Anwendung nur einem ausgewählten Benutzerkreis zugänglich sind, können Sie wahlweise das Lock-/Keycode-Konzept oder das Access-List-Konzept von openUTM verwenden (siehe openUTM-Handbuch „Konzepte und Funktionen“):

• Beim Lock/Keycode-Konzept können den Transaktionscodes (Services) und den LTERM-Partnern der UTM-Anwendung Lockcodes zugeordnet werden. Nur Benutzer oder Clients, deren Benutzerkennungen die entsprechenden Keycodes zugeordnet sind, können auf diese Objekte zugreifen. Bei der Generierung wird der Benutzerkennung ein Keyset mit einem oder mehreren Keycodes zugeordnet (USER ...,KSET=Keyset-Name). Das Keyset legt fest, auf welche Services der UTM-Anwendung der Client zugreifen darf.

• Beim Access-List-Konzept werden Rollen in Form von Keycodes definiert. Die Transaktionscodes werden mit Access-Lists geschützt. Jeder Benutzerkennung werden eine oder mehrere Rollen zugeordnet (Generierungasnweisung USER ...,KSET=). Ein Client darf über eine bestimmte Benutzerkennung nur dann auf einen Service zugreifen, wenn mindestens eine seiner Rolle in der Access-List enthalten ist. Zusätzlich können auch LTERM-Partnern Rollen zugeordnet werden, dann gilt Entsprechendes für den Zugriff über einen LTERM-Partner.

• Datensicherheit durch Benutzer-spezifische Langzeitspeicher (ULS)

  Per Generierung kann jeder UTM-Benutzerkennung ein Benutzer-spezifischer Langzeitspeicher zugeordnet werden. Auf diesen Speicher können Teilprogramme des Benutzers/Clients und vom Administrator gestartete Programme zugreifen, wobei konkurrierende Zugriffe von openUTM synchronisiert werden. Die Informationen im ULS bleiben über das Vorgangsende hinaus erhalten. Sie werden nicht gelöscht, sondern können nur durch Null-Nachrichten überschrieben werden. Der ULS dient zur Übergabe von Daten zwischen Vorgängen und Programmen des Benutzers.

  Der ULS wird in mehrere Abschnitte, sogenannte ULS-Blöcke unterteilt, ein ULS-Block muss mit der KDCDEF-Steueranweisung ULS definiert werden und ist dann für jede Benutzerkennung der UTM-Anwendung vorhanden.

Innerhalb von openUTM werden Security-Funktionen in einer Client/Server-Umgebung wie folgt realisiert:

1. Vor dem Start eines UTM-Services werden die Berechtigungsdaten, die vom Client kommen, validiert und es wird die entsprechende UTM-Benutzerkennung zusammen mit dem dazugehörigen Keyset zugeordnet. Dies entspricht etwa einem KDCSIGN eines Terminalbenutzers unmittelbar vor dem Vorgangsstart.

   Falls die Gültigkeitsdauer des Benutzerpassworts abgelaufen ist und die UTM-Anwendung mit Grace-Sign-On generiert ist, dann ist eine Anmeldung immer noch möglich.

2. Wird das Lock/Keycode oder das Access-List-Konzept eingesetzt, dann prüft openUTM, ob der Service unter dieser Benutzerkennung und über diesen LTERM-Partner gestartet werden darf. Wenn ja, dann erscheint im UTM-Service die vom Client übergebene UTM-Benutzerkennung im Kopf des Kommunikationsbereichs (KB-Kopf). Die mit dieser UTM-Benutzerkennung verknüpften Berechtigungen (Keyset) sind wirksam.

3. Die ULS-Blöcke, die der vom Client übergebenen UTM-Benutzerkennung zugeordnet sind, können verwendet werden. Melden sich mehrere Clients unter einer Benutzerkennung an, dann verwenden diese einen ULS-Block gemeinsam, da ein ULS-Block pro Benutzerkennung nur einmal existiert.

4. Am Ende des Vorgangs wird die Zuordnung (1. bis 3.) wieder aufgehoben.

Anmeldung nach Ablauf des Passwortes (Grace-Sign-On)

Ist die UTM-Anwendung mit Grace-Sign-On generiert, dann kann sich ein Client auch nach Ablauf des Passwortes noch an die Anwendung anmelden. Ist für den UPIC-Client kein Anmelde-Vorgang generiert, so erhält das Programm in diesem Fall nach einem Receive- oder Receive_Mapped_Data-Aufruf den Returncode CM_SECURITY_NOT_VALID. Zusätzliche Informationen werden in Form eines sekundären Returncodes geliefert. Der Secondary RC kann man nach dem Receive nur ausgewertet wenn bei Specify_Secondary_Return_Code() auf CM_RETURN_TYPE_PRIMARY gesetzt ist. Dieser enthält bei abgelaufenem Passwort einen der folgenden Werte:

• CM_SECURITY_PWD_EXPIRED_RETRY, wenn die Anwendung mit Grace-Sign-On generiert ist. In diesem Fall kann das Programm beim nächsten Anmelden mit Set_Conversation_Security_New_Password ein neues Passwort setzen. Dies muss sich vom bisherigen Passwort unterscheiden und den gleichen Anforderungen wie das bisherige genügen (Länge, Komplexität wie z.B. Sonderzeichen).

• CM_SECURITY_PWD_EXPIRED_NO_RETRY, wenn die Anwendung nicht mit Grace-Sign-On generiert ist. In diesem Fall kann der Client-Benutzer sich nicht mehr unter diese UTM-Benutzerkennung anmelden. Er muss den Administrator der UTM-Anwendung darum bitten, ein neues Passwort für ihn einzutragen.

Der sekundäre Returncode eines Receive- oder Receive_Mapped_Data-Aufrufs kann auch mit einem nachfolgenden CPI-C-Aufruf Extract_Secondary_Returncode abgefragt werden. Extract_Secondary_Returncode gibt den sekundären Returncode des letzten Receive- oder Receive_Mapped_Data-Aufrufs zurück.