kc_signon_str - Eigenschaften des Anmeldeverfahrens

Für den Objekttyp KC_SIGNON ist die Datenstruktur kc_signon_str definiert. In kc_signon_str liefert UTM bei KC_GET_OBJECT die Werte der Parameter zurück, über die die Anmeldung der Kommunikationspartner an die Anwendung gesteuert wird.

Datenstruktur kc_signon_str

char concurrent_terminal_signon[3];

char grace;

char pw_history[2];

char restricted;

char silent_alarm[3];

char upic;

char multi_signon;

char omit_upic_signoff;

Die Felder der Datenstruktur haben folgende Bedeutung:

concurrent_terminal_signon
	ist nur relevant, wenn in Ihrer Anwendung ein Anmelde-Vorgang generiert ist. concurrent_terminal_signon gibt an, für wieviel Prozent der generierten Benutzer gleichzeitig ein Anmelde-Vorgang aktiv sein kann, der für eine Anmeldung über ein Terminal oder eine TS-Anwendung (APPLI oder SOCKET) gestartet wurde. UTM versucht entsprechend dieser Angabe die notwendigen Betriebsmittel anzulegen.
grace
	(Grace-Sign-On) legt fest, ob ein Benutzer bei der ersten Anmeldung nach Ablauf der Passwort-Gültigkeit (siehe kc_user_str.protect_pw_time) sein Passwort noch ändern darf.
	'N'	Der Benutzer kann sein Passwort nach Ablauf der Gültigkeit nicht mehr ändern. Das Passwort kann nach Ablauf der Gültigkeit nur noch vom Administrator geändert werden.
	'Y'	Der Benutzer kann sein Passwort nach Ablauf der Gültigkeit noch ändern. Die Änderung muss innerhalb des Anmeldeverfahrens erfolgen, bevor der Benutzer vollständig angemeldet ist. Falls ein Anmelde-Vorgang aktiviert ist, dann kann das Passwort dort mit dem KDCS-Aufruf SIGN CP geändert werden, unabhängig vom Client-Typ. Ein Anmelde-Vorgang wird immer aktiviert, wenn sich ein Benutzer über eine Verbindung anmeldet, für deren Transportzugangspunkt ein Anmelde-Vorgang generiert ist. Die folgende Tabelle zeigt, wie sich die einzelnen Client-Typen bei abgelaufenem Passwort verhalten und wie das Verhalten davon abhängt, ob ein Anmelde-Vorgang aktiviert ist.

Client-Typ	Verhalten, wenn das Passwort abgelaufen ist 1
UPIC	Das Passwort kann unabhängig von der Aktivierung eines Anmelde-Vorgangs auch mit der Funktion Set_Conversation_- Security_New_Password geändert werden.
BS2000-Terminal	Bei dunkelgesteuertem Passwort fordert openUTM den Benutzer zur Änderung des Passwortes auf, unabhängig davon, ob ein Anmelde-Vorgang aktiviert ist.
	Bei nicht-dunkelgesteuertem Passwort fordert openUTM den Benutzer nur dann zur Änderung des Passwortes auf, wenn kein Anmelde-Vorgang aktiviert ist.
Terminal auf Unix-, Linux- und Windows-Systemen	openUTM fordert den Benutzer zur Änderung des Passwortes auf, unabhängig davon, ob ein Anmelde-Vorgang aktiviert ist.
TS-Anwendung	Der Benutzer kann das Passwort ohne Aktivierung eines Anmelde-Vorgangs nicht mehr ändern.

1

Das Passwort kann immer über die Administrations-Schnittstelle geändert werden (z.B. KC_MO-DIFY_OBJECT, obj_type=KC_USER). Standardmäßig werden Passwörter mit beschränkter Gültigkeitsdauer bei Änderung über die Administrations-Schnittstelle sofort auf „abgelaufen“ gesetzt. Wollen Sie dies verhindern, müssen Sie dies an der Administrations-Schnittstelle explizit anfordern.

pw_history
	gibt an, über wieviele Passwort-Änderungen für jede Benutzerkennung UTM eine Passwort-Historie führt. pw_history enthält die Anzahl der Passwörter einer Benutzerkennung, die sich UTM merkt. Ändert ein Benutzer sein Passwort und ist für das Passwort in der USER-Anweisung eine beschränkte Gültigkeitsdauer generiert, dann muss das neue Passwort sich von dem aktuellen und den letzten n Passworten, die für die Benutzerkennung gesetzt wurden, unterscheiden. Dabei ist n die Anzahl in pw_history. pw_history=0 bedeutet, dass UTM keine Passwort-Historie führt. Die Passwort-Historie ist nur bei einer Passwort-Änderung durch den Benutzer von Bedeutung, eine Änderung des Passworts per Administration ist unabhängig von der in der Historie enthaltenen Passwörtern möglich.
restricted
	gibt an, ob im 1.Teil des Anmelde-Vorgangs Datenbank-Aufrufe und Zugriffe auf globale UTM-Speicherbereiche verboten sind.
	'Y'	Im 1. Teil des Anmelde-Vorgangs sind Datenbank-Aufrufe und Zugriffe auf globale UTM-Speicherbereiche verboten.
	'N'	Im 1. Teil des Anmelde-Vorgangs sind Datenbank-Aufrufe und Zugriffe auf globale UTM-Speicherbereiche erlaubt.
silent_alarm
	gibt an, nach wievielen unmittelbar aufeinanderfolgenden erfolglosen Anmeldeversuchen eines Terminal-Benutzers UTM einen „stillen Alarm“ auslöst. Stiller Alarm bedeutet, dass UTM die Meldung K094 erzeugt. Dieser Wert ist über das Feld signon_fail der Datenstruktur kc_max_par_str änderbar, siehe Abschnitt "kc_max_par_str - Maximalwerte der Anwendung (MAX-Parameter)" .
upic	ist nur relevant, wenn in Ihrer Anwendung ein Anmelde-Vorgang generiert ist. upic gibt an, ob der Anmelde-Vorgang aktiviert wird, wenn ein UPIC-Client eine Conversation starten will.
	'Y'	Ist für den Transportsystemzugangspunkt, über den der UPIC-Client die Verbindung aufgebaut hat, ein Anmelde-Vorgang generiert, dann wird dieser vor jeder Conversation gestartet, die von dem UPIC-Client initiiert wird.
	'N'	Für UPIC-Clients wird kein Anmelde-Vorgang gestartet.
multi_signon
	gibt an, ob sich gleichzeitig mehrere Benutzer unter derselben Benutzerkennung bei der Anwendung anmelden dürfen.
	'Y'	Folgende Fälle sind zu unterscheiden: Die Benutzerkennung ist mit RESTART=NO generiert: In diesem Fall dürfen sich mehrere Benutzer gleichzeitig mit derselben Benutzerkennung bei der Anwendung anmelden. Dabei darf sich jedoch nur einer der Benutzer am Terminal anmelden. Die Benutzerkennung ist mit RESTART=YES generiert: In diesem Fall können nur mehrere Auftragnehmer-Vorgänge gleichzeitig unter einer Benutzerkennung aktiv sein, wenn die Auftragnehmer-Vorgänge über OSI TP-Verbindungen gestartet wurden und die Funktion „Commit“ ausgewählt wurde.
	'N'	Mit jeder Benutzerkennung der Anwendung darf höchstens ein Benutzer einmal angemeldet sein. D.h. für jede Benutzerkennung kann zu einer Zeit maximal ein Dialog-Vorgang aktiv sein und wenn ein Benutzer an die Anwendung angemeldet ist, dann kann für diese Benutzerkennung auch kein Auftragnehmer-Vorgang in dieser Anwendung gestartet werden.
	multi_signon hat keine Auswirkung auf das Anmelden eines Benutzers über eine OSI TP-Verbindung zur Erzeugung eines Asynchron-Auftrags.
omit_upic_signoff
	gibt an, ob die Benutzerkennung, unter der sich ein UPIC-Client anmeldet, nach Ende einer UPIC-Conversation angemeldet bleibt oder nicht.
	'Y'	Die Benutzerkennung bleibt nach Ende einer UPIC-Conversation angemeldet. Sie wird erst wieder abgemeldet, wenn die Verbindung abgebaut wird oder wenn sich über dieselbe Verbindung ein UPIC-Client mit einer anderen Benutzerkennung anmelden will. Wird vom UPIC-Client keine andere Benutzerkennung übergeben, bleibt die ursprüngliche Benutzerkennung angemeldet, d.h. vor dem Start der neuen UPIC-Conversation wird kein Anmeldevorgang gestartet. Bei Anwendungen ohne Benutzerkennungen wird gegebenenfalls vor dem Start der ersten UPIC-Conversation nach Verbindungsaufbau einmal ein Anmeldevorgang gestartet. Standard in UTM-Cluster-Anwendungen.
	'N'	Die Benutzerkennung, mit der sich ein UPIC-Client angemeldet hat, wird am Ende jeder UPIC-Conversation abgemeldet. Standard in stand-alone UTM-Anwendungen.