Auf der Registerseite Login finden Sie vier Unterseiten:
Web-Login Methoden: Web-Login ist für "
/service/login" in 3Dfindit, wird verwendet für die Abschaltung einzelner Methoden (Hostnamen oder bestimmte IP-Bereiche).Client-Login Methoden: Client-Login ist das, was im PARTdataManager und PARTadmin als Methoden zur Verfügung stehen.
OpenID Provider: Wird benötigt, wenn man mehrere auth-Anbieter haben will. Außerdem, wenn man für Api-Zugriff einen weiteren OpenID Client mit speziellen Berechtigungen haben will (Stichwort "Power Automate").
Erlaubte Web-Login Methoden [Allowed web login methods]:
Erlaubte Client-Login Methoden [Allowed client login methods]:
Tragen Sie in der Spalte Regel [Rule] in freier Eingabe eine Domäne (z.B. "CNS") oder einen Hostnamen ein (z.B. DE-AGB-NAME-01).
Klicken Sie in der Spalte Datenbanken [Databases] in ein Feld, öffnen Sie das Listenfeld mit den Optionen WINDOWS, ERP, OPENIDC, SQL,FILE undLDAP und aktivieren Sie die jeweils gewünschten.
Die Konfiguration der hier aufgeführten Optionen erfolgt unter Kategorie Rechteverwaltung [Rights administration].
Erweiterte OpenID-Authentifizierung
Die Erweiterungen stehen nun über eine grafische Benutzeroberfläche zur Verfügung. Dadurch entfällt die manuelle Bearbeitung von Konfigurationsdateien.
Erlaube Basic-Authentication ohne Server-Anforderung (Unsicher) [Enable Basic Authentication without a server request (Insecure)]: Ist die Option aktiviert, werden Benutzername und Passwort im Klartext übertragen.
Login Provider: Für AppServer-Lösungen gibt es genau einen Open ID Provider, der hier eingestellt wird. Das ist der OpenID Provider, der beim 3Dfindit-Login angezeigt wird.
Neben dem regulären Login Provider können mit Klick auf den Button beliebig viele, zusätzliche OpenID Provider konfiguriert werden. Dadurch lassen sich verschiedene Identitätsquellen parallel unterstützen, was insbesondere für Integrationen und Automatisierungsszenarien von Bedeutung ist.
Die Konfiguration umfasst folgende Einstellungen:
Auf diese Weise können unabhängig von den Einstellungen unter Rechteverwaltung [Rights administration] > Benutzerdatenbanken [User databases] > OpenID weitere Provider konfiguriert werden.
![AppServer Service > Registerseite "Login" > Registerseite "Api-Tokens [API tokens]"](https://webapi.partcommunity.com/service/help/latest/pages/de/partsolutions_user/doc/resources/img/img_e87716d638b04a628032cf4761808de2.png)
API-Token Authentifizierung für einfachen und sicheren Web-API-Zugriff
Zur Unterstützung automatisierter Zugriffe auf die Server-API wurde ein API-Token-Verfahren eingeführt. Ziel ist es, Skripten und Integrationen eine sichere Authentifizierung zu ermöglichen, ohne Benutzerkennwörter direkt verwenden zu müssen. Ergänzend dazu wurde die Authentifizierungsinfrastruktur erweitert, sodass mehrere OpenID-Provider parallel konfiguriert werden können. Der Vorteil eines separaten API-Tokens liegt auch darin, dass der API-Key einfach gelöscht werden kann ohne den betreffenden User zu kompromittieren.
API-Token für automatisierte Zugriffe
API-Tokens dienen als empfohlene Authentifizierungsmethode für skriptgesteuerte REST-API-Zugriffe. Sie sind einem bestehenden Benutzerkonto zugeordnet und übernehmen dessen Berechtigungen. Dadurch können automatisierte Anwendungen im Namen eines Benutzers auf die API zugreifen, ohne dessen Passwort zu kennen oder zu speichern.
Im Gegensatz zur Basic Authentication, bei der Benutzername und Passwort übertragen werden, können API-Tokens unabhängig vom Benutzerpasswort verwaltet werden. Wird ein Token kompromittiert, kann es widerrufen und neu erzeugt werden, ohne dass Änderungen am Benutzerkonto erforderlich sind.
Ein API-Token besteht aus einer öffentlichen Token-ID und einem Secret.
Erzeugen Sie mittels Button eine ID und ein Secret.
Tragen Sie unbedingt einen User ein. Alle User, die unter Rechteverwaltung [Rights administration] aufgenommen sind, können hier eingetragen werden.
Zusätzlich können API-Tokens optional eingeschränkt werden, beispielsweise auf:
Diese Einschränkungen reduzieren das Missbrauchsrisiko und ermöglichen eine kontrollierte Nutzung automatisierter Zugriffe.
Kopieren Sie mittels Button ID, Secret und die übrigen Einstellungen in den Zwischenspeicher.
Das Secret wird ausschließlich bei der Erstellung angezeigt und kann anschließend nicht mehr ausgelesen werden. Dadurch wird verhindert, dass Zugangsdaten nachträglich offengelegt werden.
![[Hinweis]](https://webapi.partcommunity.com/service/help/latest/pages/de/partsolutions_user/doc/images/note.png)
Nach Bestätigung mit erfolgt der Eintrag.
Erweiterte OpenID-Authentifizierung
Die Erweiterungen stehen nun über eine grafische Benutzeroberfläche zur Verfügung. Dadurch entfällt die manuelle Bearbeitung von Konfigurationsdateien.
Erlaube Basic-Authentication ohne Server-Anforderung (Unsicher) [Enable Basic Authentication without a server request (Insecure)]: Ist die Option aktiviert, werden Benutzername und Passwort im Klartext übertragen.
Login Provider: Für AppServer-Lösungen gibt es genau einen Open ID Provider, der hier eingestellt wird. Das ist der OpenID Provider, der beim 3Dfindit-Login angezeigt wird.
Neben dem regulären Login Provider können mit Klick auf den Button beliebig viele, zusätzliche OpenID Provider konfiguriert werden. Dadurch lassen sich verschiedene Identitätsquellen parallel unterstützen, was insbesondere für Integrationen und Automatisierungsszenarien von Bedeutung ist.
Die Konfiguration umfasst folgende Einstellungen:
Auf diese Weise können unabhängig von den Einstellungen unter Rechteverwaltung [Rights administration] > Benutzerdatenbanken [User databases] > OpenID weitere Provider konfiguriert werden.
Dienst läuft als Local System und benötigt keine Zugriffe auf Netzwerk-Shares (bedingt Zugriff auf Netzwerk-Shares über UNC-Pfad)
Standard-Konfiguration von Microsoft für Windows-Authentifizierung (Kerberos) funktioniert. Es muss nur der Rechnername in die Local Intranet Zone aufgenommen werden in den Browser-Einstellungen der Clients.
Dienst benötigt Zugriffe auf externe Netzwerk-Shares. Dann muss er als Service-User laufen und der SPN-Eintrag (Service Principal Name) muss korrekt gesetzt sein im AD. Und der Rechnername muss in die Local Intranet Zone aufgenommen werden in den Browser-Einstellungen der Clients.
setspn -S HTTP/servername.domain.name DOMAIN\serviceuser