Mit der Steueranweisung USER definieren Sie Benutzerkennungen für die UTM-Anwendung. Über UTM-Benutzerkennungen können sich Benutzer und Client-Programme an die UTM-Anwendung anmelden. Für Benutzerkennungen kann Folgendes definiert werden:
Komplexitätsstufe und Gültigkeitsdauer des Passwortes
Zugriffsrechte (Key-/Lockcode- oder Access-List-Konzept)
Administrationsberechtigung
Status des Benutzers
Eigenschaften der zur Benutzerkennung gehörenden USER-Queue
Startformat (BS2000-Systeme)
UTM-SAT-Administrationsberechtigung (BS2000-Systeme)
Benutzer-spezifische Sprachumgebung (BS2000-Systeme)
Art und Weise der Authentisierung (BS2000-Systeme: Passwort, Magnetstreifenkarte, Kerberos-Principal)
Mindestens einer Benutzerkennung müssen Sie die Administrationsberechtigung erteilen, damit die Anwendung administriert werden kann. Sie können mehreren Kennungen die Administrationsberechtigung geben, damit mehrere Benutzer unter den jeweiligen Kennungen gleichzeitig Administrationsfunktionen aufrufen können.
Analoges gilt auf BS2000-Systemen für die UTM-SAT-Administrationsberechtigung und das Aufrufen von SAT-Preselection-Funktionen.
Eine Anwendung kann auch ohne Benutzerkennungen generiert werden. Der Benutzer muss sich dann nicht identifizieren und openUTM verwendet intern den Namen des jeweiligen Clients als Benutzerkennung. Damit kann jeder Benutzer Administrationskommandos und auf BS2000-Systemen auch UTM-SAT-Administrationskommandos absetzen. Wird ohne Benutzerkennung gearbeitet, können einige Datenschutzfunktionen von openUTM nicht genutzt werden.
|
zusätzliche Operanden für BS2000-Systemen |
1 Nur für BS2000-Systeme
2 Kommata am Ende können entfallen, d.h. statt (8,NONE,,) können Sie (8,NONE) angeben.
username | UTM-Benutzerkennung, die der Benutzer beim Anmelden an die Anwendung bzw. ein Client beim Aufbau einer Conversation mit der Anwendung angibt. username kann max. 8 Zeichen lang sein (siehe auch LTERM-Anweisung, Operand USER=username im Abschnitt "LTERM - LTERM-Partner für Clients und Drucker definieren"). Der angegebene username muss eindeutig sein und darf keinem weiteren Objekt der Namensklasse 2 zugeordnet sein. Siehe dazu auch Abschnitt "Eindeutigkeit der Namen und Adressen" Ist username identisch mit dem Namen eines LTERM-Partners, der einer TS-Anwendung (PTYPE=APPLI oder SOCKET) oder einem remote UPIC-Client (PTYPE=UPIC-R) zugeordnet ist, dann sind die bei LTERM gegebenen Hinweise im Abschnitt "LTERM - LTERM-Partner für Clients und Drucker definieren" zu berücksichtigen. |
CARD= | Dieser Operand gilt nur für BS2000-Systeme. Für den Parameter muss Folgendes gelten: Die Angabe von CARD= schließt die Verwendung von PRINCIPAL= aus. |
position | Beginn der zu prüfenden Information auf dem Ausweis: |
characterstring | openUTM prüft beim Anmelden an die Anwendung, ob die Ausweisinformation ab der angegebenen Position mit dieser Zeichenfolge übereinstimmt. characterstring kann wie folgt angegeben werden:
Sonderzeichen kann man nur in der Form C’...’ oder X’...’ eingeben. Standard: Keine Ausweisprüfung beim Anmelden an die Anwendung. |
FORMAT= | Dieser Operand gilt nur für BS2000-Systeme. Formatkennzeichen für ein Benutzer-spezifisches Startformat. Dieses Startformat wird automatisch nach jedem erfolgreichen Anmelden an die Anwendung ausgegeben, wenn kein offener Vorgang für diesen Benutzer vorhanden ist. Befindet sich der Benutzer (USER) nach erfolgreicher Berechtigungsprüfung noch in einem Vorgang, so erscheint das Startformat nicht, stattdessen wird der letzte Dialog-Bildschirm ausgegeben (Vorgangswiederanlauf). Wird ein eigener Anmelde-Vorgang eingesetzt, kann der Name des Benutzer-spezifischen Startformats im zweiten Teil des Anmelde-Vorgangs mit einem SIGN ST-Aufruf abgefragt werden. Das Formatkennzeichen setzt sich wie folgt zusammen: +, * oder # gefolgt von einem max. 7 Zeichen langen alphanumerischen Namen (formatname). #Formate können nur im Zusammenhang mit einem Anmelde-Vorgang genutzt werden. Es bedeuten: |
+ | Beim nächsten MGET-Aufruf des Teilprogramms werden im Nachrichtenbereich (NB) jedem Inhalt eines Formatfeldes 2 Byte für das Attributfeld vorangestellt, d.h. die Feldeigenschaften sind vom Teilprogramm veränderbar. Der Formatname an der KDCS-Schnittstelle ist +formatname. |
* | Dem Inhalt eines Formatfeldes wird im Nachrichtenbereich des nächsten MGET-Aufrufs des Teilprogramms kein Byte für ein Attributfeld vorangestellt, d.h. die Feldeigenschaften sind vom Teilprogramm nicht veränderbar. Der Formatname an der KDCS-Schnittstelle ist *formatname. |
| # | bezeichnet ein Format mit erweiterten Benutzerattributen (Extended User Attributes). Feldeigenschaften und globale Formateigenschaften sind vom Teilprogramm veränderbar. Der Formatname an der KDCS-Schnittstelle ist #formatname. Standard: Kein Startformat |
KSET= | keysetname Name des Keysets, das der Benutzerkennung zugeordnet wird. Das Keyset wird mit der KSET-Anweisung definiert. Pro Benutzer (USER) kann max. ein Keyset zugeordnet werden. Das Keyset legt die Zugriffsrechte dieses Benutzerkennung für die Nutzung von Services der Anwendung und von entfernten Services (LTAC) fest, die in dieser Anwendung generiert wurden. Unter dieser Benutzerkennung können mit Lockcode bzw. Access-List geschützte Services der Anwendung nur gestartet bzw. mit Lockcode bzw. Access-List geschützte entfernte Services nur adressiert werden, wenn Folgendes zutrifft: Sowohl im zugeordneten Keyset der Benutzerkennung als auch im Keyset des LTERM-Partners, über den die Anmeldung unter der Benutzerkennung erfolgte, ist der zum Lockcode bzw. der Access-List passende Key- bzw. Zugangscode enthalten. Das Lock-/Keycode- und das Access-List-Konzept werden ausführlich im openUTM-Handbuch „Konzepte und Funktionen“ beschrieben. Eine Einführung in die Zugriffskontrolle finden Sie im gleichnamigen Abschnitt im Abschnitt "Zugriffskontrolle". Services, deren Vorgangs-TACs nicht mit Codes gesichert sind, kann der Benutzer bzw. das Client-Programm ohne Einschränkung aufrufen. Standard: kein Keyset, der Benutzer kann nur auf nicht mit Codes gesicherte Clients und LTERM-Partner zugreifen. |
LOCALE= | (lang_id,terr_id,ccsname) Dieser Operand gilt nur für BS2000-Systeme. Er definiert die Sprachumgebung des Benutzers. |
lang_id | Max. 2 Zeichen langes Sprachkennzeichen für die UTM-Benutzerkennung. Das Sprachkennzeichen kann von den Teilprogrammen der Anwendung abgefragt werden. So können die Teilprogramme Nachrichten an die Benutzerkennung in der Landessprache des Benutzers übertragen. |
terr_id | Max. 2 Zeichen langes Territorialkennzeichen für die UTM-Benutzerkennung. Das Territorialkennzeichen kann von den Teilprogrammen der Anwendung abgefragt werden. So können Sie in Nachrichten an den Benutzer die territorialen Besonderheiten in der Landessprache des Benutzers berücksichtigen. |
ccsname | (coded character set name) Der zum CCS-Namen gehörende Zeichensatz wird bei der Ausgabe von Dialog-Nachrichten verwendet, wenn der Benutzer an einem 8-Bit-Terminal angemeldet ist und kein anderer CCS-Name über Editprofil oder Format ausgewählt wird. Der Zeichensatz muss kompatibel sein zu einem erweiterten ISO- Zeichensatz, der von diesem Terminal unterstützt wird. Zum Zeitpunkt der Generierung kann openUTM diese Kompatibilität nicht überprüfen, deshalb werden von KDCDEF auch falsche Angaben akzeptiert. Standard: |
PASS= | Max. 16 Zeichen langes Passwort, das der Benutzer bei der Berechtigungsprüfung angeben muss. Das angegebene Passwort muss der im Operanden PROTECT-PW= festgelegten Komplexitätsstufe genügen. Auf BS2000-Systemen darf PASS= nicht zusammen mit PRINCIPAL= verwendet werden. Bei Angabe von *RANDOM wird für die Benutzerkennung ein zufälliges Passwort generiert, das niemandem bekannt ist. Der Benutzerkennung muss anschließend mit dem Tool KDCUPD oder per Administration ein gültiges Passwort übertragen werden. Ein durch *RANDOM erzeugtes Passwort unterliegt nicht den durch PROTECT-PW= gesetzten Bedingungen. Es ist darauf zu achten, dass spätestens zum Startzeitpunkt zumindest eine Benutzerkennung mit Administrationsberechtigung konfiguriert ist, die kein per *RANDOM erzeugtes Passwort hat, da die Anwendung sonst nicht administrierbar ist. BS2000-Systeme:
Unix-, Linux- und Windows-Systeme: Standard: 16 Leerzeichen (d.h. kein Passwort) Die Angaben haben folgende Auswirkungm auf den Anmeldedialog: |
password | BS2000-Systeme: Anmelde-Vorgang: Unix-, Linux- und Windows-Systeme: Anmelde-Vorgang: |
(password, DARK) | BS2000-Systeme: Anmelde-Vorgang: Unix-, Linux- und Windows-Systeme: Anmelde-Vorgang: |
PERMIT= | legt die Administrationsberechtigungsstufe des Benutzers innerhalb der lokalen Anwendung fest. |
ADMIN | Der Benutzer kann unter dieser Benutzerkennung Administrationsfunktionen ausführen. |
NONE | Der Benutzer darf keine Administrationsfunktionen ausführen. Standard: NONE Auf BS2000-Systemen darf der Benutzer darüber hinaus keine SAT-Preselection-Funktionen ausführen. |
SATADM | Auf BS2000-Systemen kann der Benutzer SAT-Preselection-Funktionen (UTM-SAT-Administration) ausführen. |
(ADMIN,SATADM) | Auf BS2000-Systemen kann der Benutzer Administrations- und SAT- Preselection-Funktionen ausführen. |
PRINCIPAL= | characterstring (nur auf BS2000-Systemen erlaubt) Mit dem KDCS-Aufruf INFO (KCOM=CD) kann ein Teilprogrammlauf diese Information lesen, so lange der Benutzer an diesem Client angemeldet ist. Die Angabe von PRINCIPAL schließt die Verwendung der Parameter CARD und PASS aus. characterstring muss wie folgt als alphanumerische Zeichenfolge, in Hochkommata eingeschlossen, angegeben werden: C'windowsaccount@NT-DNS-REALM-NAME' windowsaccount: Domänen-Kennung des Benutzers NT-DNS-REALM-NAME: DNS-Name der Active-Directory-Domäne. Dieser Name ist ein fester Wert für jede Active-Directory-Domäne, der schon beim Einrichten des Kerberos-Schlüssels vergeben wurde. Die Länge des angegebenen Character-Strings darf nicht größer sein, als der bei MAX PRINCIPAL-LTH angegebene Wert. Andernfalls wird der Parameter ignoriert. openUTM speichert die Kerberos-Information in der Länge ab, die sich aus dem Maximum der bei MAX PRINCIPAL-LTH und MAX CARDLTH generierten Länge ergibt. Wenn die Kerberos-Information länger ist, wird sie auf diese Länge verkürzt abgespeichert. Mit dem KDCS-Aufruf INFO (KCOM=CD) kann ein Teilprogrammlauf diese Information lesen, so lange der Benutzer an diesem Client angemeldet ist. Maximallänge: der mit MAX ...,PRINCIPAL-LTH generierte Wert, siehe Abschnitt "MAX - UTM-Anwendungsparameter definieren" Standard: keine Kerberos-Authentisierung |
PROTECT-PW= | legt die minimale Länge, die Komplexitätsstufe sowie Mindest- und Höchstgültigkeitsdauer des Benutzer-Passwortes fest. Die für PROTECT-PW angegebenen Werte müssen Sie bei der Angabe des Passworts im Operanden PASS= berücksichtigen. openUTM prüft diese auch bei der Änderung eines Passworts durch den Administrator (Administrationskommando KDCUSER, siehe openUTM-Handbuch „Anwendungen administrieren“) oder durch ein Teilprogramm (SIGN CP-Aufruf). |
length | gibt die Länge in Anzahl Zeichen an, die das Passwort mindestens haben muss. Der Administrator kann das Passwort eines Benutzers nur löschen, wenn für length=0 angegeben wird. Standard: 0 Minimalwert: Maximalwert: 16 |
NONE/MIN/MED/MAX | |
bezeichnen die Komplexitätsstufe des Passworts. | |
NONE | Es kann jede beliebige Zeichenfolge als Passwort angegeben werden. Standard: NONE |
MIN | In dem Passwort dürfen maximal 2 aufeinanderfolgende Zeichen gleich sein. Die minimale Länge des Passworts ist ein Zeichen. |
MED | In dem Passwort dürfen maximal 2 aufeinanderfolgende Zeichen gleich sein. Das Passwort muss mindestens einen Buchstaben und eine Ziffer enthalten. Die minimale Länge des Passworts ist 2 Zeichen. |
MAX | In dem Passwort dürfen maximal 2 aufeinanderfolgende Zeichen gleich sein. Das Passwort muss mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthalten. Die minimale Länge des Passworts ist 3 Zeichen. Sonderzeichen sind alle Zeichen, die von a-z, A-Z, 0-9 und Leerzeichen verschieden sind. |
maxtime | Maximale Gültigkeitsdauer: Wird maxtime angegeben, so läuft die Gültigkeit des Passworts am Ende des letzten Tages der Gültigkeitsdauer ab. Wird z.B. eine Gültigkeit von einem Tag generiert, so läuft die Gültigkeit um 24:00 Uhr des folgenden Tages ab. Wurde die Anwendung mit SIGNON GRACE=YES generiert, so wird bei einer Neu-Generierung das Passwort auf „abgelaufen“ gesetzt; der Benutzer muss dann beim ersten Anmelden ein neues Passwort vergeben. Ist die Gültigkeit abgelaufen, hängt es davon ab, wie die UTM-Anwendung generiert ist:
Wird maxtime=0 angegeben, so ist die Gültigkeitsdauer des Passworts nicht beschränkt. Standard: 0 (Gültigkeitsdauer wird nicht beschränkt) |
mintime | minimale Gültigkeitsdauer: Durch die Angabe von mintime > 0 können Sie verhindern, dass ein Benutzer, dessen Passwort abgelaufen ist, zweimal hintereinander sein Passwort ändert, und damit wieder sein ursprüngliches (= abgelaufenes) Passwort einstellt. Wird eine minimale Gültigkeitsdauer von einem Tag angegeben, so darf das Passwort frühestens um 0.00 Uhr des folgenden Tages geändert werden (Ortszeit der Generierung). Nach einer Passwortänderung durch den Administrator bzw. nach einer Neugenerierung kann der Benutzer das Passwort immer ändern, unabhängig davon, ob die minimale Gültigkeitsdauer abgelaufen ist oder nicht. mintime darf nicht größer als maxtime (maximale Gültigkeitsdauer) sein. Wird mintime=0 angegeben, so ist die minimale Gültigkeitsdauer des Passworts nicht beschränkt. Standard: 0 (keine Beschränkung) |
QLEV= | queue_level_number (queue level) openUTM berücksichtigt die Asynchron-Aufträge erst am Ende der Transaktion. Daher kann die in QLEV festgelegte Anzahl von Nachrichten für eine Message Queue überschritten werden, wenn in einer Transaktion mehrere Nachrichten für dieselbe Queue erzeugt wurden. Bei QLEV=0 können keine Nachrichten in der Queue gespeichert werden; Standard: 32767 Wird ein Wert angegeben, der größer als der Maximalwert ist, dann wird im KDCDEF-Lauf ohne Meldung der Standardwert gesetzt. |
QMODE = | (Queue Mode) |
STD | wenn der Queue-Level erreicht ist, lehnt openUTM weitere Nachrichten für die Queue mit einem negativen Returncode ab (40Z bei DPUT). |
WRAP-AROUND | openUTM nimmt auch dann noch Nachrichten für die Queue an, wenn der Queue Level bereits erreicht ist. Beim Schreiben einer Nachricht in die Queue löscht openUTM dann die älteste der in der Queue stehenden Nachrichten. Standard: STD |
Q-READ-ACL= | read-keysetname Legt Lese- und Lösch-Rechte in der USER-Queue für fremde Benutzer fest. Für read-keysetname ist ein Keyset anzugeben, das mit einer KSET- Anweisung generiert worden ist. Geben Sie Q-READ-ACL= an, dann kann ein fremder Benutzer ( Der Eigentümer (username) der USER-Queue hat immer Lese- und Löschrechte, auch wenn die Rechte mit Q-READ-ACL eingeschränkt werden. Geben Sie Q-READ-ACL= nicht an, dann hat jeder Benutzer Lese- und Lösch-Rechte in der Queue. Standard: kein Keyset |
Q-WRITE-ACL= | write-keysetname Legt Schreibrechte in der USER-Queue für fremde Benutzer fest. Geben Sie Q-WRITE-ACL= an, dann kann ein fremder Benutzer ( Der Eigentümer (username) der USER-Queue hat immer Schreibrechte, auch wenn die Rechte mit Q-WRITE-ACL eingeschränkt wurden. Geben Sie Q-WRITE-ACL= nicht an, dann hat jeder Benutzer Schreibrechte in der Queue. Standard: kein Keyset |
RESTART= | gibt an, ob openUTM Vorgangsdaten für die Benutzerkennung sichert, damit beim nächsten Anmelden unter dieser Benutzerkennung ein Vorgangswiederanlauf möglich ist. |
YES | Der zu dieser Benutzerkennung gehörige Vorgangskontext wird gesichert. Damit kann für Benutzer, die sich unter dieser Benutzerkennung anmelden, ein Vorgangswiederanlauf durchgeführt werden, wenn ein offener Vorgang für diese Benutzerkennung existiert. Beim Vorgangswiederanlauf spielen noch der Typ des Client und eventuell generierte Anmelde-Vorgänge eine Rolle. Nähere Informationen finden Sie in Abschnitt "Wiederanlauf generieren" und im openUTM-Handbuch „Einsatz von UTM-Anwendungen“. Standard: YES |
NO | Der zu dieser Benutzerkennung gehörige Vorgangskontext wird nicht gesichert, es ist kein Vorgangswiederanlauf möglich, d.h.
Wird RESTART=NO zusammen mit SIGNON MULTI-SIGNON=YES angegeben, dann können sich mehrere Benutzer gleichzeitig unter dieser Benutzerkennung bei openUTM anmelden, wobei sich nur einer der Benutzer am Terminal anmelden darf. Es können sich jedoch beliebig viele Client-Programme gleichzeitig anmelden. Explizit generierte Verbindungs-Benutzerkennungen zu UPIC-Clients werden in jedem Falle (ohne Meldung) mit RESTART=NO generiert. |
SATSEL= | Dieser Operand gilt nur für BS2000-Systeme. Er steuert die Art der SAT-Protokollierung der Ereignisse für diesen Benutzer. Bei eingeschalteter SAT-Protokollierung (MAX ...,SAT=YES) werden dann alle Ereignisse, die dieser Benutzer auslöst, entsprechend den Angaben für SATSEL protokolliert. Die Art der SAT-Protokollierung kann allgemein für alle TACs und Benutzer in der SATSEL-Anweisung festgelegt werden. Mit USER ...,SATSEL= wird zusätzlich zu den Angaben in der SATSEL-Anweisung eine Benutzer-spezifische Protokollierung festgelegt. Wird die Protokollierung einer Ereignisklasse in der SATSEL-Anweisung ausgeschlossen, so werden Ereignisse dieser Klasse nicht protokolliert (zur Verknüpfung der EVENT-, TAC- und USER-spezifischen Einstellung siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“). SATSEL kann auch bei ausgeschalteter SAT-Protokollierung (MAX ...,SAT=OFF) generiert werden. Die Anweisungen werden dann beim Start der Anwendung nicht wirksam. Sie erzeugen so eine Vorbelegung für eine SAT-Protokollierung, die im laufenden Betrieb bei Bedarf eingeschaltet werden kann (UTM-SAT-Administrationskommando KDCMSAT, siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000- Systemen“). |
NONE | Es wird keine Benutzer-spezifische Art der SAT-Protokollierung definiert. Standard: NONE |
BOTH | Es werden erfolgreiche und nicht erfolgreiche Ereignisse protokolliert. |
SUCC | Es werden nur erfolgreiche Ereignisse protokolliert. |
FAIL | Es werden nur nicht erfolgreiche Ereignisse protokolliert. |
STATUS= | gibt an, ob die Benutzerkennung beim Start der Anwendung zugelassen oder gesperrt ist. |
ON | Die Benutzerkennung ist zugelassen. Standard: ON |
OFF | Die Benutzerkennung ist gesperrt. Es kann sich kein Benutzer oder Client mit dieser Benutzerkennung anmelden, bis er vom Administrator zugelassen wird. Benutzerkennungen, die implizit oder explizit über LTERM-Anweisungen (LTERM ...,USER=) einem UPIC-Client oder einer TS-Anwendung zugeordnet sind, sind immer gesperrt. Sie können auch nicht vom UTM-Administrator zugelassen werden. Diese Benutzerkennungen werden Verbindungs-Benutzerkennungen genannt. |