Benutzerverwaltung¶
Die Benutzerverwaltung bietet die Möglichkeiten Benutzer und eine Rechtestruktur für das Projekt anzulegen. Dabei werden Rechte an Rollen geknüpft und Benutzern eine oder mehrere Rollen zugewiesen. Es gibt mindestens ein, aber auch viele Rechte pro Rolle (Werker, Einrichter). Je nach Ausprägung des Unternehmens, das eine Maschine betreibt, kann ein Mitarbeiter dort nur die Werker-Rolle ausführen, oder auch mehrere Rollen auf sich kumulieren (Werker, Einrichter, Service).
Typischerweise werden im Projektierungssystem nur die Benutzer angelegt, die der Maschinenlieferant für die Wartung einer Oberfläche durch das Servicepersonal benötigt und einem Kunden-Admin, der dann alle weitern Kunden-Logins anlegt.
Damit zur Laufzeit erstellte Benutzer der Standardbenutzerverwaltung bei einem Projektupdate nicht verloren gehen, wurde die Konfiguration in einen Laufzeitteil und in einen Projektierungsteil aufgeteilt. Die Laufzeit speichert die Einstellungen/Änderungen in einer separaten Datei (UserManagementRuntimeConfig.xml). Diese Datei wird beim ersten Start des Projektes erstellt und ist dabei eine Kopie der UserManagementConfig.xml. Wenn sich die UserManagementConfig.xml ändert (wird durch einen Zeitstempel angegeben, welcher in der Datei abgelegt ist), werden die Änderungen mit der Laufzeitkonfiguration abgeglichen.
Beim Abgleich werden folgende Regeln berücksichtigt:
Die Rechte und Gruppen werden komplett aus der Projektkonfiguration übernommen, da diese zur Laufzeit nicht verändert werden können.
Wenn eine Gruppe in der Projektierung entfernt wurde, wird bei allen zur Laufzeit erstellten Benutzern, die in dieser Gruppe Mitglied waren, die Zuordnung entfernt.
Im Designer erstellte Benutzer werden komplett übernommen.
Wenn so ein Benutzer zur Laufzeit geändert/gelöscht wurde, so werden diese Änderungen wieder rückgängig gemacht.
Ausnahme 1: Existiert bereits ein Benutzer mit dem Namen, welcher zur Laufzeit erstellt wurde, dann wird dieser Benutzer nicht verändert.
Ausnahme 2: Wurde der projektierte Benutzer zur Laufzeit verändert (er hat sein Kennwort geändert oder der Benutzer wurde bearbeitet) dann wird dieser Benutzer nicht mehr durch die Daten aus der Projektkonfiguration ersetzt. Wichtig: Nur durch ein Löschen des Benutzers zur Laufzeit oder Löschen und Neuanlegen im Designer kann so ein Benutzer per Projektupdate verändert werden. :::{important} Wird ein Benutzer im Designer gelöscht, so wird er auch zur Laufzeit gelöscht, unabhängig davon, ob der Benutzer zur Laufzeit geändert wurde. ::: Der Benutzer „Admin“ wird gesondert behandelt. Der Benutzer kann zur Laufzeit nicht gelöscht werden, er kann nicht aus der Gruppe der Administratoren entfernt werden und nur der Benutzer „Admin“ kann sich in Bezug auf Passwort, Name usw. ändern.
Über zusätzliche technische Einrichtungen können Identreader zum Anmelden z.B. mit Transpondern benutzt werden. Dies sollte in enger Abstimmung mit dem unserem Support gelöst werden.
Konfiguration Benutzerverwaltung¶
Konfiguration Sicherheit/Berechtigungen¶

Schlüsselname |
Eingabe |
Bedeutung |
---|---|---|
Passwort für Projektschutz |
Möglichkeit, ein Passwort für das Projekt zu vergeben |
|
Default Admin kann deaktiviert werden |
Möglichkeit, den Default-Admin während der Laufzeit zu deaktivieren |
Konfiguration Benutzerdatenbank (nur SCADA)¶

Schlüsselname |
Bedeutung |
---|---|
Datenablage |
Legt fest, ob die Benutzerinformationen in der Projekt-Datenbank, dem Projektpfad oder einer Dateiablage erfolgt. |
Dateipfad |
Dateiablage zur Speicherung der Benutzerdaten. Es muss sichergestellt sein, dass der Speicherort auf dem Zielsystem existiert |
Sollte nur bei Beginn der Projektierung geändert werden |
Benutzerverwaltung allgemein¶
Mit dem Benutzerverwaltungseditor können bereits in der Design-Phase die benötigten Benutzer und Richtlinien festgelegt werden. In der Laufzeit können diese Benutzer geändert bzw. neue Benutzer angelegt werden. Die Erstellung von Benutzergruppen und die Zuordnung von Rechten zu der Benutzergruppe sind in der Laufzeit nicht möglich.
Um das Erscheinungsbild der Dialoge für die Benutzerverwaltung zur Laufzeit zu individualisieren, können diese über den Styleguide benutzerspezifisch angepasst werden (s. Kapitel „Styleguide“).
Benutzer¶
Mit dem Editor „Benutzer“ werden die zur Laufzeit benötigten Benutzer erstellt bzw. bearbeitet.

Der Editor dient zum Anlegen, Bearbeiten und Löschen von Benutzern. Bei jedem Projekt existiert standardmäßig der Benutzer „Admin“, welcher der Benutzergruppe „Administratoren“ zugeordnet ist. Der Benutzer „admin“ lässt sich auch nicht löschen und dient zur Administration des Systems. Mit ihm können andere Gruppen und Benutzer modifiziert werden, weshalb er nur als Fallback genutzt werden sollte wenn sich z.B. niemand mehr anmelden kann.
Important
Wird das Passwort des admin-Users vergessen und es gibt keinen weiteren Benutzer mehr mit Systemrechten, gibt es außer dem Zurücksetzen der kompletten Benutzerdatenbank keine Möglichkeit, wieder auf das System zuzugreifen! Es ist dann zwingend ein Projektupdate über den Designer notwendig!
Deshalb sollten für das eigentliche Rechtesystem immer eigene Benutzer und Gruppen definiert und mit entsprechenden Rechten versehen werden. Um neue Benutzer anzulegen, wird das Kontextmenü geöffnet und der Eintrag Benutzer erstellen bzw. kopieren angewählt, wenn ein bereits bestehender Benutzer selektiert ist.

Es wird ein leerer Benutzer erstellt, dem Attribute zugewiesen werden müssen. In der folgenden Tabelle sind die Attribute dargestellt, die ein Benutzer haben kann.
Important
Der Benutzername Admin ist vom System vergeben und kann zur Laufzeit nicht gelöscht werden und auch nicht aus der Administrator-Gruppe entfernt werden. Nur wenn man als Admin eingeloggt ist, kann der Admin-Benutzer geändert werden.
Attribut |
Bedeutung |
---|---|
Benutzername |
Gibt den Namen an, über den sich der Benutzer anmeldet. Maximal 31 Zeichen möglich |
Vollständiger Name |
Hier wird der Vollständige Name des Benutzers angegeben. Maximal 100 Zeichen möglich. |
Beschreibung |
Hier kann ein Text zur Benutzerbeschreibung angegeben werden. Dieser Text kann mehrsprachig sein. Maximal 255 Zeichen möglich. |
Kennwort |
Kennwort zur Authentifizierung des Benutzers |
Kennwortalterung |
Mit dieser Option wird die Kennwortalterung für den User aktiviert/deaktiviert, wenn dies in den Richtlinien aktiviert wurde. D.h. das Kennwort muss nach „X“ Tagen geändert werden. Der Zeitraum für die Kennwortalterung wird in den Kennwortrichtlinien festgelegt |
Kennwort muss beim nächsten Login geändert werden. |
Ist diese Option aktiviert, wird der Benutzer beim nächsten Login gezwungen ein neues Passwort zu vergeben. |
Gruppe |
Gibt die Gruppe an, zu welcher der Benutzer zugeordnet ist. |
Angabe der Email Adresse |
|
Handy |
Angabe der Handynummer |
Telefon |
Angabe der Telefonnummer |
Notification Typ |
Bevorzugter Typ der Benachrichtigung. Mögliche Werte: E-Mail, SIP-SMS, PageControl SMS, PageControl Phone |
Notification Gruppe |
Mitglied in folgenden Benachrichtigungs-Gruppen |
Sprache |
Angabe der Sprache für diesen Benutzer |
Important
Der Benutzername darf nicht doppelt vorhanden oder leer sein. Das Gestik-Kennwort wird zu einem späteren Zeitpunkt umgesetzt.
Richtlinien¶
Unter diesem Punkt werden alle Einstellungen bezüglich der Passwortsicherheit angepasst. Standardmäßig sind alle Kennwortrichtlinien aktiviert oder mit Default-Werten gesetzt.
Um eine FDA-Konformität der Benutzerverwaltung zu erreichen, müssen entsprechend restriktive Einstellungen für die Benutzerverwaltung vorgenommen werden (siehe Whitepaper FDA-Konformität). Passwörter werden in allen Fällen verschlüsselt abgelegt und können nicht ausgelesen werden.
Kontorichtlinien¶

Unter der Richtliniengruppe Kontorichtlinien wird die Kontosperrungsschwelle definiert. Standardmäßig wird nach drei erfolglosen Eingabeversuchen das Konto gesperrt.
Important
Der Punkt „Kontensperrungsschwelle“ gilt auch für den Benutzer „Admin“.
Kennwortrichtlinien¶

Die zweite Richtliniengruppe sind die Kennwortrichtlinien. In der nachfolgenden Tabelle sind die verfügbaren Kennwortrichtlinien dargestellt. Die Kennwortrichtlinien werden bereits bei Vergabe der Passwörter im Designer überprüft.
Richtlinie |
Bedeutung |
---|---|
Kennwortalterung |
Durch Aktivieren der Kennwortalterung läuft das Kennwort nach Ablauf des maximalen Kennwortalters ab und muss neu vergeben werden. |
Maximales Kennwortalter |
Gibt an, nach wie vielen Tagen das Kennwort abläuft. |
Erzwingen sicherer Kennwörter |
Das Kennwort entspricht bei Aktivierung dieser Richtlinie den Vorgaben für sichere Passwörter (Es werden die Richtlinien mind. ein Groß- und Kleinbuchstabe, mind. eine Zahl und mind. ein Sonderzeichen ausgewertet). |
Mindestens ein Groß- und Kleinbuchstabe |
Das Kennwort muss mindestens einen Groß- und Kleinbuchstaben enthalten |
Mindestens eine Zahl |
Im Kennwort muss mindestens eine Zahl enthalten sein. |
Mindestens ein Sonderzeichen |
Im Kennwort muss mindestens ein Sonderzeichen enthalten sein. |
Muss den Komplexitätsanforderungen entsprechen |
Kennwort entspricht den Komplexitätsanforderungen (Die Richtlinien Minimale Kennwortlänge und „Erzwinge sicheres Kennwort“ werden ausgewertet). |
Minimale Kennwortlänge |
Hier wird die minimal nötige Kennwortlänge festgelegt. |
Kennwortchronik |
Ist die Kennwortchronik aktiv, werden die letzten fünf Passwörter des Benutzers gespeichert und können nicht als neue Kennwörter vergeben werden. |
Rollen und Rechte¶
Dieser Editor gliedert sich in zwei Teile. Im oberen findet man die Möglichkeit eine neue Gruppe anzulegen. Im unteren Abschnitt kann man neue Aufgaben-/ Rechtegruppen definieren.
Rollen-/Gruppen¶
In diesem Bereich werden neue Gruppen angelegt, bestehende bearbeitet oder bestimmte gelöscht. Es gibt auch die Möglichkeit eine bestehende Gruppe zu kopieren. Standardmäßig ist die Gruppe „Administratoren“ vordefiniert, welche auch nicht gelöscht werden kann. Weitere können über das Kontextmenü erzeugt werden.

In der nachfolgenden Tabelle sind die Attribute von Gruppen dargestellt.
Attribut |
Bedeutung |
---|---|
Rollen-/Gruppenname |
Gibt den Namen der Benutzergruppe an, der Name darf nicht leer bzw. doppelt vorhanden sein. Der Grupenname ist ein TextItem. |
Beschreibung |
Hier kann der Benutzer eine Beschreibung für die jeweilige Gruppe angeben. |
Aufgabe / Recht |
Hier gibt der Benutzer an, welche Aufgaben oder Rechte eine Gruppe besitzt. |
Bereich |
Auswahl des Bereiches möglich, für den die Rolle auswhälbar ist, wenn das Projekt mehrere besitzt. |
Externes Gruppen Mapping |
Mapping einer internen Benutzergruppe auf eine externe. Entweder Microsoft AD oder ein OAuth Provider. besitzt. |
Important
Der Gruppenname und die Gruppenbeschreibung können mehrsprachig projektiert werden.
Nachdem die Gruppe erstellt ist, können der Gruppe Rechte zugeordnet werden. Die Rechtespalte zeigt den Namen des Rechts an. Wenn mehr als ein Recht der Gruppe zugeordnet wurde, wird „[mehr]“ angezeigt. Über den Button wird ein Dialog geöffnet, über dem die Rechte ausgewählt werden können.

Alle verfügbaren Rechte werden gruppiert nach Rechtegruppe in diesem Dialog aufgeführt. Über die Spalte „Zugeordnet“ kann das Recht der Gruppe zugeordnet werden. Wird „Recht verweigert“ aktiviert, hat die Benutzergruppe keinen Zugriff auf das Recht. Die Änderungen werden beim Klicken auf den OK-Button übernommen, bei Klick auf den Cancel-Button verworfen.
Sonderstellung Administratoren-Gruppe: Die Gruppe „Administrators“ ist eine vom System vordefinierte Gruppe, deren Mitglieder ALLE Systemrechte haben und andere Gruppen und Benutzer modifizieren können.
Dies gilt auch für den Standardbenutzer „admin“, der automatisch Mitglied dieser Gruppe ist und auch nicht aus dieser gelöscht werden sollte.
Es wird empfohlen, diese Gruppe tatsächlich nur für Administrationszwecke zu verwenden und für das eigentliche Rechtesystem immer eigene Gruppen zu definieren und mit Rechten zu versehen. Ein Benutzer kann nur durch einen anderen Benutzer aus der Administratoren-Gruppe in diese aufgenommen, entfernt oder modifiziert werden, auch wenn eine andere Gruppe das Recht „Fremde Gruppe zuweisen“ bzw. „Benutzer ändern“ oder „Kennwort anderer Benutzer ändern“ besitzt.
Aufgaben-/Rechte¶
Im Bereich „Aufgaben-/ Rechtegruppe“ können die Konto- und Kennwortrichtlinien konfiguriert werden.

Es wird eine leere Rechtegruppe erstellt, denen verschiedene benutzerspezifische Rechte zugewiesen werden können.

Es wird ein Recht erstellt, dass später einem Symbol oder Bild hinzugefügt werden kann.
Ansichten¶
Für die Benutzerverwaltung gibt es zwei Ansichten Benutzerliste und Benutzergruppen, die jeweils in einem Grid (Benutzerverwaltungs-Grid) zur Laufzeit dargestellt werden können.
Benutzerlistenansicht¶
Die Benutzerlistenansicht kann alle Attribute eines Benutzers in Tabellenform darstellen.

Benutzergruppenansicht¶
Die Benutzergruppenansicht kann die angelegten Benutzergruppen in Tabellenform darstellen.

Rechte und Bereiche¶
Für alle Eingabemöglichkeiten in Bildern können neben den Rechten auch Bereiche zugeordnet werden. Damit wird das funktionale Recht einen Wert zu ändern mit dem geografischen Recht, dies nur an bestimmten Clients ausführen zu dürfen, verknüpft. Somit kann eine kritische Sollwertänderung neben einem bestimmten Recht auch auf die Ausführung über ein bestimmtes Bedienpanel eingeschränkt werden.
Die unten angefügte Grafik verdeutlicht den Zusammenhang zwischen Benutzer, Benutzergruppen sowie Rechte und Bereiche:

Rechtesystem in der Laufzeit¶
Dialog Benutzer anmelden¶
Mit dem Anmelde-Dialog authentifizieren sich die Benutzer am System. Wird die Anmeldung durch Betätigung des „Schließen“-Symbols (oben rechts) abgebrochen, so bleibt ein evtl. angemeldeter Benutzer angemeldet. Über den Anmelden Button wird die Anmeldung durchgeführt.
Wenn ein Fehler bei der Anmeldung auftritt, beispielsweise falsches Kennwort, wird die Fehlermeldung direkt im Dialog angezeigt:

Auch Hinweistexte werden auf diese Art angezeigt. Beispielsweise wird angezeigt, dass das Kennwort in x Tag(en) abläuft.

Der Dialog schließt sich dann nach ein paar Sekunden von selbst. (Standardmäßig nach 5 Sekunden)
Prüfung der Rechte¶
Die Überprüfung der benötigten Rechte, um eine Aktion ausführen zu können, wird in der Laufzeit an zwei Stellen ausgeführt. Wenn man an ein Objekt mehrere Rechte knüpft, dann müssen alle Rechte vorhanden sein. Eine Veränderung der Rechte eines angemeldeten Benutzers, greift erst, wenn sich dieser ab- und erneut angemeldet hat
Prüfung im Client¶
Rechte z.B. an Eingaben werden im Client überprüft.
Prüfung im Server¶
Rechte, die an Tags definiert sind, werden serverseitig geprüft. Damit könnten auch Sollwertänderungen auf Basis eines gehackten Clients vom Server abgefangen und zurückgewiesen werden.
Authentifizierung (nur SCADA)¶
In PROCON-WEB ist in der Benutzerverwaltung neben der internen Benutzerverwaltung auch eine OAuth2 (Tokenauthentifizierung) integriert. Diese kann auch extern zur Verfügung gestellt werden um um externen Anwendungen die Validierung von Benutzern zu ermöglichen.
Zusätzlich besteht die Möglichkeit auch externe OAuth2 Provider anstatt des PROCON-WEB internen OAuth2 Providers zu nutzen um zb externe Benutzerverwaltungen anzubinden. Dafür muss ein entsprechendes Mapping der Benutzergruppen stattfinden.
Es stehen 3 Auswahlmöglichkeiten (Authentifizierungsart) zur Verfügung:
Intern (aktuelles internes PROCON-WEB-eigenes UserManagement)
Microsoft Active Directory (es wird aktuell nur MS AD unterstützt)
OAuth2 Provider
Konfiguration im Designer¶

Für die Auswahl „intern“ müssen keine weiteren Einstellungen getroffen werden.
Für die Auswahl „Microsoft Active Directory“ müssen die Active Directory Domain und der Domänenname der Actve Directory Domäne erfasst werden.
Für die Auswahl „OAuth2 Provider“ stehen folgende Einträge zur Verfügung:
Attribut |
Bedeutung |
---|---|
Token-Ablaufzeit |
Zeit in Minuten in der der Token Gültigkeit hat Default 120 |
Issuer |
Issuer der in den JWT-Token eingetragen wird. Damit wird ermittelt, wer den Token ausgestellt hat. Bei Verwendung mehrerer PROCON-WEB Instanzen sollte der Issuer in jeder Instanz eineindeutig sein |
Internen OAuth2-Server für Extern freischalten |
Der PROCON-WEB interne OAuth2 Server wird für externe Applikationen freigeschaltet. Er ist über folgende URL erreichbar: ‚http://{MACHINENAME}:{HTTPPORT}/user-management/api/v1/oauth2/token‘ (MACHINENAME ist der Name/IP Adresse der Maschine, auf der der Dienst läuft, HTTPPORT ist der konfigurierte http Port) |
HTTP-Port |
HTTP Port unter dem der interne OAuth2 Server für externe Nutzung verfügbar ist |
Nats Port |
Port für die interne Kommunikation der Benutzerverwaltung |
Autologin |
Der Benutzeranmeldungsdialog wird immer angezeigt, wenn kein Benutzer angemeldet ist oder ein Logout erfolgt |
Benutzername |
Bei der Eingabe eines Benutzernamens wird dieser Benutzer automatisch beim Start der Visualisierung angemeldet. |
Wird kein Benutzer angegeben erscheint der Login Dialog |
|
Passwort |
Das Passwort des Benutzers der beim Start der Visualisierung automatisch angemeldet wird |
Laufzeit mit externer Authentifizierung¶
Prinzipiell ist bei einer externen Authentifizierung (sowohl über Microsoft Active Directory als auch über OAuth Provider) immer auch eine Authentifizierung mit PROCON-WEB eigenen Benutzern möglich. Falls eine Authentifizierung am externen Server (Active Directory Domäne oder externer OAuth Provider) scheitert wird im zweiten Schritt eine interne Authentifizierung versucht. Existiert der Benutzer als interner PROCON-WEB User (Er ist als Benutzer im Designer projektiert oder zur Laufzeit neu angelegt) so erfolgt der Login als dieser Benutzer
Microsoft Active Directory Authentifizierung
Der Benutzer-Login funktioniert ganz normal wie ohne Microsoft Active Direcotry-Ankopplung.
Wird der Domänencontroler nicht gefunden, oder der Zugriff verweigert ist zunächst kein Login möglich, dann funktioniert eine Anmeldung NUR mit internen Benutzern aus PROCON-WEB.
Wird ein Benutzer einmal erfolgreich über die Domäne authentifiziert, so wird dieser “gepuffert”, ein späterer Login ist dann auch möglich, wenn der Domänencontroller offline sein sollte.
Domänenbenutzer können in PROCON-WEB nur bedingt geändert werden. Änderungen der Gruppenzugehörigkeit werden z.B. auch durch die Domäne geregelt, d.h. das Entfernen eines Benutzers aus einer Gruppe mit Domänenmapping muss in der Domäne erfolgen.
Es können jedoch Benutzerinformationen angepasst werden, die z.B. für Notification notwendig sind (Email, Telefonnummern, Notification-Gruppenzuordnungen) oder ein IdentCode für eine Legic-Anmeldung.
Kennwortrichtlinien, gesperrte Benutzer usw. werden komplett von der Domäne verwaltet, Einstellungen von PROCON-WEB werden ignoriert. Die Komplexität des Passworts muss zusätzlich zu den Einstellungen der Domäne auch den Einstellungen in PROCON-WEB genügen.
Im UserManager werden zunächst nur Benutzer aus PROCON-WEB angezeigt. Domänen-Benutzer können nur angezeigt werden, wenn ein Domänen-Benutzer angemeldet ist Es werden nur diejenigen Benutzer der Domäne angezeigt, die auch in einer “gemappten Gruppe” Mitglied sind. Sie müssen direkt in der Gruppe Mitglied sein. Deaktivierte oder gesperrte Benutzer werden ausgeblendet.
OAuth2 Authentifizerung
Ähnlich wie bei der Microsoft Active Directory Kopplung funktioniert auch bei einer Authentifizerung über OAuth2 der Benutzer-Login ganz normal wie ohne die externe Ankopplung.
Zusätzlich besteht bei der OAuth2 Authentifizerung auch die Möglichkeit, sich direkt mit einem Token-String zu authentifzieren falls dieser von der externen OAuth2 Infrastruktur zur Verfügung gestellt wurde. Das kann zb durch eine Email passieren oder eine Textdatei auf einem USB-Stick, die dem Anwender zur Verfügung gestellt wurde. Der Token muss dann über die Zwischenablage eingefügt oder eingetippt werden.
Im Gegensatz zu Microsoft Active Directory ist jedoch KEIN puffern des Bentzers auf dem System möglich, es muss für die Authentifizierung IMMER der OAuth Service verfügbar sein, da die Token eine gewisse Ablaufzeit haben und immer neu erstellt werden müssen.
OAuth Benutzer können in PROCON-WEB auch nicht geändert werden. Die Gruppenzugehörigkeit wird durch die Rollen aus dem OAuth Service fest vorgegeben und damit auch die Rechte.
Auch zusätzliche Benutzerinformationen können nicht angepasst werden, da alle Benutzerinformationen über den Token bei der Authentifizierung bereitgestellt werden. Dadurch ist in dem Szenario auch keine IdentCode und Legic-Anmeldung möglich.
Im UserManager werden daher auch immer nur Benutzer aus PROCON-WEB angezeigt.
PROCON-WEB Viewer (nur SCADA)¶
Über einen „normalen“ Browser wie den Internet Explorer oder Firefox ist es nicht möglich einen Ident-Reader anzukoppeln. Um diese Einschränkung zu umgehen, wurde ein eigener PROCON-WEB Viewer entwickelt.
Beschreibung¶
Im Runtime-Verzeichnis gibt es eine neue Datei Namens „PROCON-WEB_Viewer.exe“. Diese ist eine Rahmenapplikation, die ein Browser-Control enthält. Zudem kann Sie den Ident Reader über eine COM-Schnittstelle ankoppeln und die Informationen des Ident-Readers zur Visualisierung weitergeben.
Bedienung und Funktionen¶
Die Datei „PROCON-WEB_Viewer.exe“ besitzt keine Abhängigkeiten und kann daher auf jedes Windows basierende System mit.NET Framework 4.5.2 oder neuer kopiert und ausgeführt werden. Es wird die Browser Engine des auf dem System vorhandenen Internet-Explorer verwendet. Daher muss sichergestellt werden, dass dieser auf dem aktuellen Stand (10 oder neuer) ist. Beim ersten Start der Applikation erscheint ein Konfigurations-Fenster:

Hier muss die URL des PROCON-WEB Server angegeben werden. Zudem können weitere Optionen gesetzt werden.
Kiosk mode: Ist der Harken gesetzt wird PROCON-WEB Viewer ohne Rahmen im Full-Screen-Modus gestartet. Ein Verlassen der Visualisierung ist nur über ESC-ESC möglich, wenn der Benutzer die dafür notwendigen Rechte hat.
Ident-Reader¶
Konfiguration Identreader (nur SCADA)¶

Schlüsselname |
Eingabe |
Bedeutung |
---|---|---|
Identreader Typ |
Standardwert: Deaktiviert |
Einstellung wie der Identreader funktionieren soll, falls vorhanden |
String-Variable |
Standardwert: DefaultString Variable |
String-Variable, die den gelesenen Token des Identreaders entgegen nimmt |
Skript |
Standardwert: DefaultSkript |
Skript, das nach Anmeldung per Identreader ausgeführt werden soll |
Voraussetzungen Ident-Reader¶
Der Ident-Reader muss den Code in Textform ausgeben und mit einem Carriage-Return und/oder einem New-Line-Feed beenden.
Verwenden des Ident Reader für die Authentifizierung¶
Ist in der Projektkonfiguration eingestellt, dass der Ident Reader für die Authentifizierung genutzt werden soll, erscheint im „Benutzer bearbeiten“-Dialog der Benutzerverwaltung ein Textfeld „Ident Code“. Während der Dialog geöffnet ist, kann ein Token aufgelegt werden und der Inhalt des Textfeldes wird automatisch befüllt.

Im Anschluss kann durch Auflegen eines Tokens die Benutzeranmeldung durchgeführt werden.
Verwenden des Ident Reader für benutzerdefinierte Aktionen¶
Alternativ kann der Ident Reader für benutzerdefinierte Aktionen benutzt werden. In der Projektkonfiguration kann eine Textvariable und/oder ein Skript angegeben werden. Wird ein Token auf den Ident Reader aufgelegt wird der Inhalt des Tokens auf die Textvariable geschrieben und im Anschluss das angegebene Skript ausgeführt.
Login mit Token¶
Login via URL Parameter „token”¶
Wie auch über andere Parameter (z.B. “picture” oder “client”) kann auch ein Nutzer direkt über die URL eingeloggt werden.
Ein Beispiel wäre dann:
Eingabe in die URL-Zeile: http://localhost/?token=jwt123
Note
Der Wert “jwt123” wäre kein vallider Token!
Weitere Informationen zu JWT sind hier zu finden:
Automatischer Login bei Systemstart¶
Der Client versucht sich in folgender Reihe einzuloggen, ist eine Option nicht gegeben, so wird die nächste verwendet:
Login via Url-Parameter
Login über Nutzer, welcher „angemeldet bleiben“ aktiviert hat
Login des Defaultnutzers, falls vorhanden
Laden der zuletzt verwendeten Sprache (kein User)
Defaultnutzer¶
Es ist nun möglich einen Defaultnutzer zu konfigurieren. Dieser Defaultnutzer wird automatisch eingeloggt, wenn kein anderer Nutzer eingeloggt ist. Sobald der Nutzer einen Logout-Aufruf vornimmt, so wird der aktuelle Nutzer ausgeloggt und der Defaultnutzer eingeloggt.
Clientscript Funktion „loginByJWT“¶
Es gibt eine neue Clientscriptfunktion mit der folgenden Signatur.
loginByJWT(token:string):void: Promise<void>
Diese Funktion erlaubt es ebenfalls, wie auch der Login über URL-Parameter die Authentifizierung über einen Token.
OAUth2 Provider¶
Unter diesem Menüitem können eigene Provider für die Authentifizierung erstellt werden.

Ein Provider hat folgende Werte:
Attribut |
Bedeutung |
|
---|---|---|
Issuer (Name) |
Name des Providers wie er im dekodierten Token angegeben ist |
|
URL-Weiterleitung |
Die URL über die die Authentifizerung stattfindet |
|
Algorithmus |
Es kann zwischen ES256 und RS256 ausgewählt werden |
|
Aktiviert |
ob der Provider aktiv ist oder nicht |
|
PublicKeyFile |
Das PubicKeyFile des Providers muss an der Stelle ausgewählt werden damit es zur Validierung verwendet werden kann |
|
Benutzer Name |
Das Feld im dekodierten Token, in dem der Benutzername (login-Name) abgelegt ist |
|
Mapping Name |
Das Feld im dekodierten Token, in dem die externen Benutzerrollen / Benutzergruppen abgelegt sind. Es kann eine einzelne Beenutzergruppe oder ein String-Array von mehreren Gruppen geliefert werden. Diese Namen entsprechen den externen Gruppennamen im Gruppenmapping. |
|
Rollen |
Das Passwort des Benutzers der beim Start der Visualisierung automatisch angemeldet wird |
|
JWKS verwenden (JSON Web Key Set) |
Diese Konfiguration kann alternative zu einem PublicKeyFile benutzt werden |
|
JWKS-Typ (aktiv, wenn „JWKS verwenden“ angehakt wurde) |
Es kann zwischen URL und Datei ausgewählt werden |
|
JWKS (aktiv, wenn „JWKS verwenden“ angehakt wurde) |
Entweder eine Url oder ein json-File (je nach Auswahl unter JWKS-Typ) |
|
Zeiteingabe aktivieren |
||
Zeit (in Minuten) |
aktiv, wenn „Zeiteingabe aktivieren“ angehakt wurde |