SIGNON - Anmeldeverfahren steuern

Mit der Steueranweisung SIGNON können Sie Optionen und Parameter für das Anmeldeverfahren Ihrer UTM-Anwendung festlegen. Durch die SIGNON-Parameter wird die Anmeldung von Benutzern gesteuert.

Die Parameter UPIC, RESTRICTED und CONCURRENT-TERMINAL-SIGNON sind nur relevant, wenn ein Anmelde-Vorgang generiert ist.

Geben Sie für die Operanden von SIGNON ungültige Werte ein, dann setzt KDCDEF den jeweiligen Standardwert. Dies geschieht z.T. ohne Ausgabe einer entsprechenden Meldung (siehe folgende Operandenbeschreibung).

SIGNON

[ CONCURRENT-TERMINAL-SIGNON=%_value ]   [ ,GRACE={ NO | YES } ]  [ ,MULTI-SIGNON={ YES | NO } ]  [ ,OMIT-UPIC-SIGNOFF={ YES | NO } ]  [ ,PW-HISTORY=number ]   [ ,RESTRICTED={ YES | NO } ]  [ ,SILENT-ALARM=number1 ]   [ ,UPIC={ YES | NO } ]

CONCURRENT-TERMINAL-SIGNON=%_value

ist nur relevant, wenn in Ihrer Anwendung ein Anmelde-Vorgang generiert ist.
In CONCURRENT-TERMINAL-SIGNON geben Sie an, für wieviel Prozent der generierten Benutzer gleichzeitig ein Anmelde-Vorgang aktiv sein kann. openUTM versucht, entsprechend dieser Angabe, die notwendigen Betriebsmittel anzulegen.

Der Wert %_value bezieht sich nur auf Anmelde-Vorgänge, die für Terminal-Benutzer und TS-Anwendungen gestartet werden.

Standard: 25 (%)
Minimalwert: 1 (%)
Maximalwert: 100 (%)

Wenn Sie für %_value einen Wert < 1 oder > 100 angeben, setzt KDCDEF ohne Meldung den Standardwert von 25 % ein.

GRACE=

(Grace-Sign-On)
legt fest, ob ein Benutzer nach Ablauf der Passwort-Gültigkeit (siehe USER PROTECT-PW, Abschnitt "USER - Benutzerkennungen definieren") sein Passwort noch ändern darf.

    YES

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 Transportzugriffspunkt 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.
HTTP-Client	Der Benutzer kann das Passwort nicht ändern.

¹ Das Passwort kann immer über die Administrations-Schnittstelle geändert werden. 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.

Nach einer Neu- oder Änderungsgenerierung sind folgende Besonderheiten zu beachten:

• Wird das Passwort eines Benutzers nach einer Neugenerierung (mit anschließendem KDCUPD-Lauf) auf Grund der Erhöhung der Komplexität ungültig, so kann der Benutzer sein Passwort nur im Anmelde- Vorgang (mit SIGN CP) ändern.
• Nach einer Neugenerierung (ohne nachfolgenden KDCUPD-Lauf) erzwingt openUTM beim ersten Anmelden die Änderung von Passwörtern, die mit einer Gültigkeitsdauer generiert sind.

    NO

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.

Standard: NO

MULTI-SIGNON=

legt fest, ob sich ein Benutzer gleichzeitig mehrfach unter derselben Benutzerkennung an die Anwendung anmelden kann.

Der Operand MULTI-SIGNON hat keine Auswirkung auf das Empfangen und Starten von Asynchron-Vorgängen über OSI TP.

    YES

Folgende Fälle sind zu unterscheiden:

• Die Benutzerkennung ist mit USER..,RESTART=NO generiert:

  In diesem Fall darf sich ein Benutzer mehrfach gleichzeitig mit dieser Benutzerkennung bei der Anwendung anmelden. Dabei darf jedoch nur eine Anmeldung über ein Terminal erfolgen. Über UPIC-, APPLI-, SOCKET- und OSI TP-Verbindungen können zusätzlich weitere Anmeldungen erfolgen.

• Die Benutzerkennung ist mit USER...,RESTART=YES generiert:

  In diesem Fall darf sich ein Benutzer höchstens einmal an die Anwendung anmelden, jedoch können in der Anwendung für den Benutzer zusätzlich mehrere Auftragnehmer-Vorgänge aktiv sein, sofern diese über OSI TP-Verbindungen gestartet und die Functional Unit „Commit“ ausgewählt wurde.

    NO

Jede Benutzerkennung darf gleichzeitig höchstens einmal angemeldet sein und für jede Benutzerkennung kann maximal ein Dialog-Vorgang gleichzeitig aktiv sein.

Standard: YES

OMIT-UPIC-SIGNOFF=  

legt fest, ob ein Benutzer, der sich über eine UPIC-Verbindung angemeldet hat, nach Ende der Conversation angemeldet bleibt oder nicht.

    YES

Wenn sich ein Benutzer über eine UPIC-Verbindung angemeldet hat, dann bleibt er nach Ende der Conversation angemeldet. Er wird erst abgemeldet,

• wenn vor dem Start einer neuen UPIC Conversation über dieselbe Verbindung im UPIC-Protokoll ein anderer User übergeben wird,

• oder wenn die Verbindung abgebaut wird.

Wenn im UPIC-Protokoll kein anderer User übergeben wird, wird vor dem Start der UPIC Conversation kein Anmeldevorgang gestartet.

Wenn die Anwendung ohne User generiert ist, kommt es für eine bestehende Verbindung nie zu einem Wechsel der UserId. Deshalb wird in diesem Fall nur vor dem Start der ersten Conversation nach dem Verbindungsaufbau gegebenenfalls ein Anmeldevorgang gestartet.

Standard in UTM-Cluster-Anwendungen.

    NO

Wenn sich ein Benutzer über eine UPIC-Verbindung angemeldet hat, wird er am Ende der UPIC-Conversation abgemeldet.

Standard in stand-alone Anwendungen.

PW-HISTORY=

number

legt fest, ob und über wieviele Passwort-Änderungen openUTM eine Passwort-Historie führen soll.

Geben Sie für number einen Wert > 0 an, dann führt openUTM eine Passwort-Historie. number ist die Anzahl der Passwörter einer Benutzerkennung, die openUTM sich merkt.

Ändert ein Benutzer sein Passwort und ist für das Passwort in der USER-Anweisung eine maximale Gültigkeitsdauer generiert, dann muss das neue Passwort sich von dem aktuellen und den letzten number Passwörtern, die für die Benutzerkennung gesetzt wurden, unterscheiden.
number=0 bedeutet, dass openUTM keine Passwort-Historie führt.

Standard: 0
Minimalwert: 0
Maximalwert: 10

Geben Sie für PW-HISTORY einen Wert > 10 an, dann setzt KDCDEF den Maximalwert 10 ein.

Die Passwort-Historie gilt nur für den Benutzer, eine Änderung des Passworts per Administration ist unabhängig von der Historie möglich.

RESTRICTED=

legt fest, ob im 1. Teil des Anmelde-Vorgangs DB-Aufrufe und Zugriffe auf globale UTM-Speicher verboten sind.

    YES

Im 1. Teil des Anmelde-Vorgangs sind DB-Aufrufe und Zugriffe auf globale UTM-Speicher verboten.

    NO

Im 1. Teil des Anmelde-Vorgangs sind DB-Aufrufe und Zugriffe auf globale UTM-Speicher erlaubt.

Standard: YES

SILENT-ALARM=

number1

legt die Anzahl der aufeinander folgenden erfolglosen Anmeldeversuche über einen LTERM-Partner oder von einem Benutzer fest, nach der ein stiller Alarm (K094-Meldung) ausgelöst wird. Die Meldung wird nach number1 aufeinander folgenden ungültigen Anmeldeversuchen eines Benutzers oder von einem Client aus ausgegeben.

Standard:  10
Minimalwert: 1
Maximalwert: 100

UPIC=

ist nur relevant, wenn in Ihrer Anwendung ein Anmelde-Vorgang generiert ist.
Mit UPIC= legen Sie fest, ob der Anmelde-Vorgang aktiviert wird, wenn ein UPIC-Client eine Conversation starten will.

    YES

Wenn für den Transportsystemendpunkt (BCAMAPPL), über den sich der UPIC-Client mit der Anwendung verbunden hat, ein Anmeldevorgang generiert ist, wird dieser vor jeder UPIC Conversation gestartet.

    NO

Für einen UPIC-Client wird kein Anmelde-Vorgang gestartet.

Standard: NO