Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Zugangskontrolle (Identifizierung und Authentisierung)

Für die Realisierung der Zugangskontrolle bietet Ihnen openUTM folgende Möglichkeiten:

  • Definition von logischen Anschlusspunkten für Clients und Partner-Server

  • Benutzerkennungen und Passwörter beim Einsatz von Terminals

  • Benutzerkennungen und Passwörter beim Einsatz von Client-Programmen

  • Benutzerkennungen und Passwörter beim Einsatz von OSI TP-Partner-Anwendungen (Anwendungs-übergreifendes Benutzerkonzept)

  • Zugangsschutz durch Ausweisprüfung beim Einsatz von Terminals

  • Verwendung von Kerberos auf BS2000-Systemen beim Einsatz von Terminals

  • Stiller Alarm bei wiederholten Fehlversuchen

  • Selbst programmierte Berechtigungsprüfungen - Event-Service SIGNON

In den folgenden Abschnitten werden diese Möglichkeiten kurz erläutert. Das genaue Format der entsprechenden Generierungsanweisungen finden Sie im openUTM-Handbuch „Anwendungen generieren“. Die KDCADMI-Aufrufe sind im Detail im openUTM-Handbuch „Anwendungen administrieren“ beschrieben.

Definition von logischen Anschlusspunkten für Clients und Partner-Server

Jeder Client und jeder Partner-Server, der eine UTM-Anwendung nutzen will, muss dieser UTM-Anwendung bekannt sein. Ein Client oder Partner-Server ist einer Anwendung dann bekannt, wenn er einem in der Konfiguration der UTM-Anwendung definierten logischen Anschlusspunkt zugeordnet ist.

LTERM-Partner - Anschlusspunkte für Clients

Die logischen Anschlusspunkte für Clients heißen LTERM-Partner (Logical TERMinal) und werden mit der KDCDEF-Anweisung LTERM generiert. Mit der KDCDEF-Anweisung PTERM (Physical TERMinal) wird dem LTERM-Anschlusspunkt ein „realer“ Client zugeordnet. LTERM-Partner und PTERM-Zuordnungen lassen sich auch dynamisch bei laufender Anwendung definieren (KDCADMI-Aufruf KC_CREATE_OBJECT).


Bild 32: Anschluss von Clients über LTERM-Partner

Bei der in Bild 32 dargestellten Beispiel-Konfiguration könnten die Clients A, B und C mit der UTM-Anwendung arbeiten. Obwohl auch Client D über eine Leitung zum Server-Rechner verfügt, hat er keinen Zugang zur UTM-Anwendung, weil ihm in der Konfiguration der Anwendung kein LTERM-Partner zugeordnet ist.

Falls gewünscht, können Sie dieses strenge Zuordnungsschema durch die Nutzung von LTERM-Pools lockern. LTERM-Pools ermöglichen einer festlegbaren Anzahl von Clients den Zugang zur UTM-Anwendung, ohne dass jeder Client explizit einem LTERM-Partner zugeordnet werden müsste. Falls Sie einen LTERM-Pool einsetzen, wird jedem Client, der sich an die UTM-Anwendung anschließen will und nicht explizit generiert ist, automatisch ein LTERM-Partner aus dem Pool zugeordnet.

(OSI-)LPAP-Partner - Anschlusspunkte für Partner-Server

Die logischen Anschlusspunkte für Partner-Server heißen LPAP-Partner (Logical Partner APplication) oder, falls über das OSI TP-Protokoll gearbeitet werden soll, OSI-LPAP-Partner. Sie werden entsprechend mit den KDCDEF-Anweisungen LPAP bzw. OSI-LPAP definiert. Für die Zuordnung der „realen“ Partner-Anwendung steht die KDCDEF-Anweisung CON (CONnection) bzw. OSI-CON zur Verfügung.

Definition von Benutzerkennungen und Passwörtern

Für UTM-Anwendungen können Benutzerkennungen definiert werden, entweder bereits bei der Generierung mit der KDCDEF-Anweisung USER oder dynamisch mit dem KDCADMI-Aufruf KC_CREATE_OBJECT.

Wird eine UTM-Anwendung mit UTM-Benutzerkennungen generiert, dann können Benutzer-spezifische Passwörter vereinbart werden.

Für die Passwortvergabe kann eine bestimmte Mindestlänge und eine bestimmte Komplexitätsstufe zur Bedingung gemacht werden. Ebenso lässt sich für jeden Benutzer die minimale und maximale Gültigkeitsdauer seines Passwortes festlegen.

Die Passwörter der Benutzerkennungen werden von openUTM verschlüsselt abgespeichert, d.h. sie sind in einem Dump nicht erkennbar. Passwörter werden bei der Kommunikation mit Clients und Terminal-Emulationen verschlüsselt, sofern diese die Verschlüsselung unterstützen.

Benutzer haben im laufenden Betrieb die Möglichkeit, das eigene Passwort zu ändern, sofern für die UTM-Anwendung ein entsprechender Service erstellt wurde.

Benutzerkennungen und Passwörter beim Einsatz von Terminals

Alle Terminal-Benutzer, die mit einer UTM-Anwendung arbeiten wollen, müssen sich dann gegenüber der UTM-Anwendung durch Angabe ihrer Benutzerkennung identifizieren. Diese Berechtigungsprüfung wird auch KDCSIGN genannt. Sofern ein Passwort generiert wurde, muss dies ebenfalls angegeben werden.

Terminal-Benutzer haben bei der Anmeldung die Möglichkeit, das eigene Passwort selbst zu ändern (in openUTM auf BS2000-Systemen nur bei dunkelgesteuertem Passwort).

Benutzerkennungen und Passwörter beim Einsatz von Client-Programmen

Das Identifizierungs- und Authentisierungskonzept von openUTM steht Ihnen auch beim Einsatz von UTM-Client-Programmen zur Verfügung.

UPIC-Clients und OpenCPIC-Clients

UPIC- und OpenCPIC-Clients übergeben der UTM-Anwendung Benutzerkennung und Passwort über spezielle Aufrufe:

  • Für CPI-C sind das die Aufrufe Set_Conversation_Security_User_ID und Set_Conversation_Security_Password.

  • Bei XATMI dienen hierfür die Parameter usrname und passwd des Aufrufs tpinit.

Bei Einsatz des UTM-Client mit Trägersystem UPIC können Sie das Passwort auch ändern (Aufruf Set_Conversation_Security_New_Password). Der Client kann anhand eines Returncodes feststellen, dass die Gültigkeitsdauer eines Passwortes abgelaufen ist.

Vor dem Start eines Services validiert openUTM die Berechtigungsdaten, die vom Client übergeben werden, und ordnet die jeweilige Benutzerkennung und das entsprechende Berechtigungsprofil zu (siehe "Zugriffskontrolle (Autorisierung)"). Dies entspricht dem KDCSIGN eines Terminal-Benutzers.

Ein und dasselbe Client-Programm kann also unter verschiedenen Benutzerkennungen mit jeweils individuellen Berechtigungsprofilen arbeiten.

TS-Anwendungen

Das Identifizierungs- und Authentisierungskonzept von openUTM steht Ihnen beim Einsatz von Transportsystem-Anwendungen nur dann zur Verfügung, wenn Sie für diesen Transportsystem-Zugriffspunkt einen Anmelde-Vorgang definiert haben, siehe "Zugangskontrolle (Identifizierung und Authentisierung)".

Bei TS-Anwendungen gilt die Anmeldung immer für die Dauer der Verbindung. Beim Aufbau der Verbindung startet openUTM den Anmelde-Vorgang, validiert die Berechtigungsdaten, die vom Anmelde-Vorgang übergeben werden, und ordnet die jeweilige Benutzerkennung und das entsprechende Berechtigungsprofil für die Dauer der Verbindung zu.

Wenn ein Client-Programm keine Berechtigungsdaten übergibt, wird eine fest dem LTERM-Partner zugeordnete Verbindungs-Benutzerkennung angemeldet. Somit können auch solche Clients mit UTM-Anwendungen arbeiten, denen keine Protokolle und Schnittstellen zur Übergabe von Berechtigungsdaten zur Verfügung stehen - allerdings nur mit einem Berechtigungsprofil der Verbindungs-Benutzerkennung.

Genaue Informationen zum Security-Konzept beim Anschluss von Client-Programmen finden Sie in den openUTM-Client-Handbüchern.

Benutzerkonzept bei Server-Server-Kommunikation über OSI TP

Das Benutzerkonzept von openUTM steht Ihnen bei der Server-Server-Kommunikation über OSI TP Anwendungs-übergreifend zur Verfügung. Bei der Adressierung des Partners können Sie im APRO-Aufruf einen Security-Typ wählen:

N

(none)
Es werden keine Berechtigungsdaten an den Auftragnehmer übergeben.

S

(same)
Es wird die Benutzerkennung an den Auftragnehmer übergeben, unter der der lokale Service läuft.

P(program)
Es werden im Programm explizit spezifizierte Werte als Benutzerkennung und Passwort an den Auftragnehmer übergeben.

Zugangsschutz bei Terminals durch Ausweisprüfung

Benutzerkennungen für eine UTM-Anwendung können so konfiguriert werden, dass der Zugang zu der Anwendung über eine Benutzerkennung nur mit einem speziellen Ausweis möglich ist. Dazu muss am Terminal ein entsprechender Leser vorhanden sein. Wird während des Arbeitens mit der UTM-Anwendung der Ausweis aus dem Leser entfernt, bricht openUTM die Verbindung zum Terminal ab. Bei Terminals mit entsprechenden Lesern kann somit der Zugang zur UTM-Anwendung abhängig gemacht werden von einer Benutzerkennung, einem Passwort und vom Besitz eines gültigen Ausweises.

Einsatz von Kerberos mit openUTM auf BS2000-Systemen

Für Terminals ermöglicht openUTM auf BS2000-Systemen zusammen mit SECOS den Einsatz von Kerberos (RFC1510). Kerberos ist ein Netzwerk-Authentisierungsprotokoll, das am Massachussets Institute of Technology (MIT) entwickelt wurde. Es handelt sich um ein Sicherheitssystem, das auf kryptographischen Verschlüsselungsverfahren basiert. Bei einer Authentisierung mit Kerberos werden keine Kennwörter im Klartext über das Netzwerk gesendet. Dadurch wird das Abfangen von Kennwörtern im Netzwerk verhindert. Außerdem entfällt damit die Verwaltung von Kennwörtern eines Benutzers für verschiedene Anwendungen, d.h. Kerberos ermöglicht zugleich einen Single-Sign-On zu verschiedenen Anwendungen.

Kerberos arbeitet mit symmetrischer Verschlüsselung, d.h. alle Schlüssel liegen an zwei Stellen vor, beim Eigentümer eines Schlüssels (Principal) und beim KDC (Key Distribution Center).

Stiller Alarm bei wiederholten Fehlversuchen

Werden von einem Client oder einem OSI TP-Partner aus nacheinander mehrere erfolglose (fehlerhafte) Anmeldeversuche unternommen, dann erzeugt openUTM intern eine Meldung mit dem Standardziel SYSLOG (System-Protokolldatei) und wahlweise auch MSGTAC, um auf mögliche Eindringversuche hinzuweisen. Die Anmeldeversuche eines Benutzers müssen nicht von demselben Client aus erfolgen. Erfolglose Anmeldeversuche eines Benutzers können damit auch beim Zugang über Terminal-Pool überwacht werden.

Dadurch haben Sie die Möglichkeit, in solchen Fällen gezielte Maßnahmen einzuleiten, z.B. mittels automatischer Administration (siehe "Automatische Administration") die Verbindung abbauen. Sie können in der Konfiguration festlegen, nach wieviel fehlerhaften Anmeldeversuchen diese Meldung erzeugt werden soll.

Automatischer Verbindungsabbau

Bei der Generierung können Sie festlegen, wie lange die UTM-Anwendung nach Transaktionsende - oder auch nach Dialogausgabe innerhalb einer Transaktion - maximal auf eine Eingabe von einem Client warten soll. Erfolgt in dieser Zeit keine Eingabe, dann wird die Verbindung zum Client abgebaut. Ist der Client ein Terminal, dann wird dabei zusätzlich eine Meldung ausgegeben. Wenn beispielsweise ein Benutzer nach Beendigung seiner Arbeit vergessen hat, sich bei der UTM-Anwendung abzumelden, wird durch diesen automatischen Verbindungsabbau die Wahrscheinlichkeit für einen unberechtigten Zugang zur UTM-Anwendung verringert.

Selbst programmierte Berechtigungsprüfungen - Event-Service SIGNON

Im Standardfall werden die Terminal-Benutzer bei der Anmeldung an eine UTM-Anwendung durch vorgegebene UTM-Meldungen aufgefordert, Benutzerkennung und Passwort anzugeben und ggf. den Ausweis einzulegen.

Mit dem Event-Service SIGNON können Sie den Anmeldungsdialog für Ihre Anwendung jedoch auch individuell gestalten und zusätzlich zu den Berechtigungsprüfungen von openUTM eigene Berechtigungsprüfungen durchführen. Sie können mehrere SIGNON-Services definieren und damit die Anmelde-Vorgänge Typ-spezifisch gestalten (Terminal, Clients mit Trägersystem UPIC, Transportsystem-Anwendungen, ...).

Mit openUTM werden Beispiel-Programme für einen SIGNON-Service ausgeliefert - sowohl die übersetzten Objekte als auch die COBOL-Sourcen. Diesen SIGNON-Service, der einen Anmeldungsdialog mit Formaten realisiert, können Sie als Vorlage verwenden und individuell abändern, oder auch unverändert einsetzen.

Informationen über Programmierung und Einsatzmöglichkeiten von SIGNON-Services finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“.