Schnittstellen: Security Levels und Authentifizierung: Unterschied zwischen den Versionen
| Zeile 1: | Zeile 1: | ||
| − | + | '''''Hinweis:''' Dieser Artikel ist "work in progress", die beschriebenen Sicherheitsfeatures für das DataGatewayServer sind auf unserer Entwicklungs-roadmap für Ende Q1/2024 und demnach noch nicht umgesetzt.''<br><br>Grundsätzlich kann das HVS32 ohne Bedenken in Cloud-Umgebungen betrieben werden, sofern die Verbindung vom Vorsystem (ERP bzw. WMS, nachfolgend der Einfachheit halber nur ERP genannt) zum HVS32 in einem gemeinsamen, gesicherten, internen Netzwerk ist.<br>Wenn das Versandsystem HVS32 allerdings öffentlich erreichbar sein muss - also sich das Vorsystem (ERP/WMS) und das Versandsystem HVS32 nicht im gleichen Netzwerk (LAN, vLAN, vNET, private cloud) befinden - muss die Kommunikations-Verbindung der beiden Systeme abgesichert werden.<br>Dies impliziert, dass sowohl die Verbindung verschlüsselt als auch jede eingehende Verbindung authentifiziert und autorisiert werden muss.<br> | |
| − | '''''Hinweis:''' Dieser Artikel ist "work in progress", die beschriebenen Sicherheitsfeatures für das DataGatewayServer sind auf unserer Entwicklungs-roadmap für Ende Q1/2024 und demnach noch nicht umgesetzt.''<br><br> | ||
| − | Grundsätzlich kann das HVS32 ohne Bedenken in Cloud-Umgebungen betrieben werden, sofern die Verbindung vom Vorsystem (ERP bzw. WMS, nachfolgend der Einfachheit halber nur ERP genannt) zum HVS32 in einem gemeinsamen, gesicherten, internen Netzwerk ist.<br> | ||
| − | Wenn das Versandsystem HVS32 allerdings öffentlich erreichbar sein muss - also sich das Vorsystem (ERP/WMS) und das Versandsystem HVS32 nicht im gleichen Netzwerk (LAN, vLAN, vNET, private cloud) befinden - muss die Kommunikations-Verbindung der beiden Systeme abgesichert werden.<br> | ||
| − | Dies impliziert, dass sowohl die Verbindung verschlüsselt als auch jede eingehende Verbindung authentifiziert und autorisiert werden muss.<br> | ||
=Security Levels (Infrastruktur)= | =Security Levels (Infrastruktur)= | ||
| Zeile 20: | Zeile 16: | ||
=Authentifizierung= | =Authentifizierung= | ||
Authentifizierungs-Mechanismen können nur als "sicher" bezeichnet werden, wenn diese in Kombination mit anderen Sicherheits-Mechanismen wie HTTPS/SSL genutzt werden. Die Verschlüsselung ist mittels HTTPS unter Verwendung von TLSv1.2 oder TLSv1.3 (sofern vom Client unterstützt) möglich.<br> | Authentifizierungs-Mechanismen können nur als "sicher" bezeichnet werden, wenn diese in Kombination mit anderen Sicherheits-Mechanismen wie HTTPS/SSL genutzt werden. Die Verschlüsselung ist mittels HTTPS unter Verwendung von TLSv1.2 oder TLSv1.3 (sofern vom Client unterstützt) möglich.<br> | ||
| − | Die folgenden Authentifizierungs-Optionen beziehen sich ausschließlich auf die [https://interface.heidler-strichcode.de?version=v2 RESTv2 Schnittstelle] | + | |
| + | Die folgenden Authentifizierungs-Optionen beziehen sich '''ausschließlich''' auf die [https://interface.heidler-strichcode.de?version=v2 RESTv2 Schnittstelle] | ||
==Basic Authentication== | ==Basic Authentication== | ||
| − | Die Basisauthentifizierung ist ein einfaches Authentifizierungsschema, welches in das HTTP-Protokoll integriert ist. Der Client sendet HTTP- | + | Die Basisauthentifizierung ist ein einfaches Authentifizierungsschema, welches in das HTTP-Protokoll integriert ist. Der Client sendet in jeder HTTP-Anfrage den Autorisierungsheader, welcher Benutzername und Passwort enthält. |
| + | |||
| + | Der Autorisierungsheader lautet '''Authorization''' und beinhaltet den Benutzer und Passwort Base64 codiert im Format ''- Basic <Benutzer>:<Passwort>''. | ||
| + | |||
| − | + | Die Benutzerverwaltung erfolgt im DataGatewayServer. Dort können neue Benutzer angelegt und gelöscht werden. | |
| − | Beispiele: | + | '''Hinweis:''' Mit zunehmender Anzahl von gültigen Benutzern steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird. |
| + | |||
| + | |||
| + | Beispiele Autorisierungsheader: | ||
<div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| − | <div style="font-weight:bold;line-height:1.6;">Anfrage</div> | + | <div style="font-weight:bold;line-height:1.6;">Beispielheader für eine Anfrage</div> |
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
In diesem Beispiel wird der Benutzer ''heidler'' mit dem Passwort ''Wolfschlugen'' verwendet. | In diesem Beispiel wird der Benutzer ''heidler'' mit dem Passwort ''Wolfschlugen'' verwendet. | ||
| Zeile 41: | Zeile 44: | ||
<br> | <br> | ||
<div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| − | <div style="font-weight:bold;line-height:1.6;">Rückmeldung bei fehlgeschlagener Authentifizierung</div> | + | <div style="font-weight:bold;line-height:1.6;">Rückmeldung bei fehlgeschlagener Authentifizierung - 401 Unauthorized</div> |
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
| − | Sollte die Authentifizierung aufgrund von falschem Benutzer | + | Sollte die Authentifizierung aufgrund von falschem Benutzer oder Passwort fehlschlagen, so wird der HTTP-Code '''401 Unauthorized''' mit der Fehlermeldung ''"Unauthorized acces"'' im Body quittiert. |
<syntaxhighlight lang="http"> | <syntaxhighlight lang="http"> | ||
| Zeile 57: | Zeile 60: | ||
==Digest Access Authentication== | ==Digest Access Authentication== | ||
| − | HTTP Digest Access Authentication ist ein Authentifizierungsmechanismus, der in das HTTP-Protokoll integriert ist und dazu dient, die Sicherheit von Webanwendungen zu erhöhen. Im Gegensatz zur einfachen Basisauthentifizierung überträgt Digest Access Authentication keine Benutzernamen und Passwörter im Klartext, sondern verwendet kryptografisch sichere Methoden.<br> | + | HTTP Digest Access Authentication ist ein Authentifizierungsmechanismus, der in das HTTP-Protokoll integriert ist und dazu dient, die Sicherheit von Webanwendungen zu erhöhen. Im Gegensatz zur einfachen Basisauthentifizierung überträgt Digest Access Authentication keine Benutzernamen und Passwörter im Klartext, sondern verwendet kryptografisch sichere Methoden.<br>Bei der Digest-Authentifizierung sendet der Client eine Anfrage an den Server, der daraufhin eine "Nonce" (eine einmalige Zufallszahl) zurückgibt. Der Client kombiniert diese Nonce mit Benutzername, Passwort, Anfrage-Methode und URI und erstellt einen "Digest" (Prüfzusammenstellung). Dieser Digest wird dann an den Server gesendet.<br>Der Server kann den Digest überprüfen, indem er denselben Algorithmus auf der Serverseite anwendet und die berechneten Werte vergleicht. Da der Digest mit Hilfe der Nonce und kryptografisch sicheren Techniken erstellt wird, schützt die Digest-Authentifizierung effektiv vor Angriffen wie Passwortdiebstahl und MitM-Angriffen. |
| − | Bei der Digest-Authentifizierung sendet der Client eine Anfrage an den Server, der daraufhin eine "Nonce" (eine einmalige Zufallszahl) zurückgibt. Der Client kombiniert diese Nonce mit Benutzername, Passwort, Anfrage-Methode und URI und erstellt einen "Digest" (Prüfzusammenstellung). Dieser Digest wird dann an den Server gesendet.<br> | + | |
| − | Der Server kann den Digest überprüfen, indem er denselben Algorithmus auf der Serverseite anwendet und die berechneten Werte vergleicht. Da der Digest mit Hilfe der Nonce und kryptografisch sicheren Techniken erstellt wird, schützt die Digest-Authentifizierung effektiv vor Angriffen wie Passwortdiebstahl und MitM-Angriffen.<br> | + | |
| + | Die Benutzerverwaltung erfolgt im DataGatewayServer. Dort können neue Benutzer angelegt und gelöscht werden. | ||
| + | |||
| + | '''Hinweis:''' Mit zunehmender Anzahl von gültigen Benutzern steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird. | ||
| + | |||
| + | |||
| + | Beispiele: | ||
| + | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| + | <div style="font-weight:bold;line-height:1.6;">Rückmeldung für nonce</div> | ||
| + | <div class="mw-collapsible-content"> | ||
| + | In der erstanfrage wird im Header keine Autorisierung geliefert, da vom Server zuerst die nonce abgefragt werden muss. In der Rückmeldung befindet sich dann die nonce zusammen mit weiteren Informationen im HTTP-Header '''Www-authenticate'''. | ||
| + | |||
| + | Diese Anfrage wird mit dem HTTP-Code '''401 Unauthorized''' und der Fehlermeldung ''"Authentication required!"'' im Body quittiert. | ||
| + | <syntaxhighlight lang="http"> | ||
| + | HTTP/1.1 401 Unauthorized | ||
| + | Www-authenticate: Digest realm="Restricted Area",qop="auth",nonce="079ae550-11c1-40bf-9ee9-7cce5f1dd70e",opaque="opaque" | ||
| + | Date: Mon, 26 Feb 2024 10:21:41 GMT | ||
| + | Content-type: application/json | ||
| + | Content-length: 24 | ||
| + | |||
| + | Authentication required! | ||
| + | </syntaxhighlight> | ||
| + | </div></div> | ||
| + | <br> | ||
| + | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| + | <div style="font-weight:bold;line-height:1.6;">Anfrage nach erhaltener nonce</div> | ||
| + | <div class="mw-collapsible-content"> | ||
| + | Nachdem die nonce aus der ersten Anfrage extrahiert und der "Digest" erstellt worden ist, erfolgt die Anfrage für die Verarbeitung mit dem HTTP-Header '''Authorization'''. | ||
| + | |||
| + | <syntaxhighlight lang="http"> | ||
| + | POST <ENDPOINT> HTTP/1.1 | ||
| + | Content-Type: application/json | ||
| + | Accept: application/json | ||
| + | Cache-Control: no-cache | ||
| + | Authorization: Digest username="<BENUTZER>", realm="Restricted Area", nonce="079ae550-11c1-40bf-9ee9-7cce5f1dd70e", uri="<ENDPOINT>", algorithm="MD5", qop=auth, nc=00000001, cnonce="PoYGQC6K", response="ce3fb921e353290142e34ac886694a4c", opaque="opaque" | ||
| + | </syntaxhighlight> | ||
| + | </div></div> | ||
| + | |||
| + | |||
| + | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| + | <div style="font-weight:bold;line-height:1.6;">Rückmeldung bei fehlgeschlagener Authentifizierung</div> | ||
| + | <div class="mw-collapsible-content"> | ||
| + | Bei einer ungültigen Autorisierung (Verwendung vom HTTP-Header '''Authorization''') wird der HTTP-Code '''401 Unauthorized''' mit der Fehlermeldung ''"client credentials invalid!"'' im Body zurück gemeldet. | ||
| + | |||
| + | <syntaxhighlight lang="http"> | ||
| + | HTTP/1.1 401 Unauthorized | ||
| + | Date: Mon, 26 Feb 2024 10:45:40 GMT | ||
| + | Content-type: application/json | ||
| + | Content-length: 27 | ||
| + | |||
| + | client credentials invalid! | ||
| + | </syntaxhighlight> | ||
| + | </div></div> | ||
==API Keys== | ==API Keys== | ||
| − | Die API-Key-Authentifizierung ist eine einfache Methode zur Sicherung von API-Zugriffen. Bei dieser Authentifizierungsmethode erhält der Benutzer einmalig einen eindeutigen API-Schlüssel (API-Key). Dieser Schlüssel | + | Die API-Key-Authentifizierung ist eine einfache Methode zur Sicherung von API-Zugriffen. Bei dieser Authentifizierungsmethode erhält der Benutzer / Hostsystem einmalig einen eindeutigen API-Schlüssel (API-Key). Dieser Schlüssel muss dann bei jeder API-Anfrage im Header mit gesendet werden.<br>Der Server überprüft den empfangenen API-Key, um sicherzustellen, dass die Anfrage von einem autorisierten Benutzer oder einer autorisierten Anwendung stammt.<br> |
| − | Der Server überprüft den empfangenen API- | + | |
| − | Der API- | + | Der API-Key muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, diesen regelmäßig zu zu aktualisieren, um die Sicherheit zu gewährleisten. |
| + | |||
| + | |||
| + | Der API-Key wird im DataGatewayServer verwaltet. Dort kann ein neuer Key generiert werden. Es können mehrere API-Keys generiert werden. | ||
| + | |||
| + | '''Hinweis:''' Mit zunehmender Anzahl von gültigen API-Keys steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird. | ||
Beispiele: | Beispiele: | ||
<div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | <div class="toccolours mw-collapsible mw-collapsed" style="overflow:auto;"> | ||
| − | <div style="font-weight:bold;line-height:1.6;">Anfrage</div> | + | <div style="font-weight:bold;line-height:1.6;">Beispielheader für eine Anfrage</div> |
<div class="mw-collapsible-content"> | <div class="mw-collapsible-content"> | ||
In diesem Beispiel wird der API-Key ''apikey_heidler'' verwendet. | In diesem Beispiel wird der API-Key ''apikey_heidler'' verwendet. | ||
| Zeile 97: | Zeile 157: | ||
==OAuth 2.0== | ==OAuth 2.0== | ||
===Client Credentials=== | ===Client Credentials=== | ||
| − | OAuth 2.0 Client Credentials ist eine Authentifizierungs-Methode im OAuth 2.0-Protokoll, die es einer Anwendung ermöglicht, sich beim Authorization Server (Authentifizierungsserver) zu authentifizieren. Dies ist besonders nützlich für den Zugriff von Anwendungen auf APIs ohne Benutzerbeteiligung und eignet sich gut für server-seitige Kommunikation zwischen Diensten.<br> | + | OAuth 2.0 Client Credentials ist eine Authentifizierungs-Methode im OAuth 2.0-Protokoll, die es einer Anwendung ermöglicht, sich beim Authorization Server (Authentifizierungsserver) zu authentifizieren. Dies ist besonders nützlich für den Zugriff von Anwendungen auf APIs ohne Benutzerbeteiligung und eignet sich gut für server-seitige Kommunikation zwischen Diensten.<br>Das ERP wird am Server registriert und erhält eine eindeutige Client-ID und ein Client Secret.<br>Inital wird dann von dem ERP eine HTTP-POST-Anfrage an den Authorization Server gesendet, welche die Client-Anmeldeinformationen (Client ID und Client Secret) beinhaltet. Im Response wird ein Access-Token und ein Refresh-Token zurück gemeldet.<br>Das ERP sendet nun für die Authentifizierung bei jeder Anfrage das Access-Token im Authorization Header der HTTP-Anfragen mit. Wenn das Access-Token abgelaufen ist, kann mit dem Refresh-Token ein neuer Access-Token angefragt werden. Im Falle einer mehrfachen Nutzung eines Refresh-Tokens werden automatisch alle Refresh-Tokens und Access-Tokens gesperrt.<br>Das Client Secret muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, das Client Secret regelmäßig zu zu aktualisieren, um die Sicherheit weiter zu erhöhen. |
| − | Das ERP wird am Server registriert und erhält eine eindeutige Client-ID und ein Client Secret.<br> | + | |
| − | Inital wird dann von dem ERP eine HTTP-POST-Anfrage an den Authorization Server gesendet, welche die Client-Anmeldeinformationen (Client ID und Client Secret) beinhaltet. Im Response wird ein Access-Token und ein Refresh-Token zurück gemeldet.<br> | + | |
| − | Das ERP sendet nun für die Authentifizierung bei jeder Anfrage das Access-Token im Authorization Header der HTTP-Anfragen mit. Wenn das Access-Token abgelaufen ist, kann mit dem Refresh-Token ein neuer Access-Token angefragt werden. Im Falle einer mehrfachen Nutzung eines Refresh-Tokens werden automatisch alle Refresh-Tokens und Access-Tokens gesperrt.<br> | + | Die Client-ID und Client-Secret werden im DataGatewayServer verwaltet. Dort können neue Client-IDs angelegt oder bestehende Client-IDs gelöscht werden. |
| − | Das Client Secret muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, das Client Secret regelmäßig zu zu aktualisieren, um die Sicherheit weiter zu erhöhen. | + | |
| + | '''Hinweis:''' Mit zunehmender Anzahl von gültigen Client-IDs steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird. | ||
| + | |||
| + | |||
| + | Beispiele: | ||
===Authorization Code=== | ===Authorization Code=== | ||
Diese Authentifizierungs-Methode ist ausschließlich über das Authentifzierungssystem [[IRIS_Cloudsystem|IRIS Cloudsystem]] möglich. | Diese Authentifizierungs-Methode ist ausschließlich über das Authentifzierungssystem [[IRIS_Cloudsystem|IRIS Cloudsystem]] möglich. | ||
Version vom 26. Februar 2024, 12:55 Uhr
Hinweis: Dieser Artikel ist "work in progress", die beschriebenen Sicherheitsfeatures für das DataGatewayServer sind auf unserer Entwicklungs-roadmap für Ende Q1/2024 und demnach noch nicht umgesetzt.
Grundsätzlich kann das HVS32 ohne Bedenken in Cloud-Umgebungen betrieben werden, sofern die Verbindung vom Vorsystem (ERP bzw. WMS, nachfolgend der Einfachheit halber nur ERP genannt) zum HVS32 in einem gemeinsamen, gesicherten, internen Netzwerk ist.
Wenn das Versandsystem HVS32 allerdings öffentlich erreichbar sein muss - also sich das Vorsystem (ERP/WMS) und das Versandsystem HVS32 nicht im gleichen Netzwerk (LAN, vLAN, vNET, private cloud) befinden - muss die Kommunikations-Verbindung der beiden Systeme abgesichert werden.
Dies impliziert, dass sowohl die Verbindung verschlüsselt als auch jede eingehende Verbindung authentifiziert und autorisiert werden muss.
Security Levels (Infrastruktur)
Zur Absicherung der Netzwerk-Brücke gibt es keine zu 100% perfekte oder sichere Lösung. Meist muss man sich für einen Kompromiss je nach Fall entscheiden. In der Infrastruktur können jedoch bereits diverse Security Levels implementiert werden, um die Sicherheit maßgeblich zu erhöhen.
LAN / vLAN / vNET / private cloud / VPN
Befinden sich die beiden Server in einem gemeinsamen Netzwerk, bzw. liegt eine gesicherte Netzwerk-Brücke via VPN zu Grunde, bietet dies grundlegend die beste Basis für eine sichere Datenkommunikation zwischen dem Vorsystem und dem Versandsystem HVS32.
S2S (Server-to-Server)
Bei einer ungesicherten Netzwerk-Brücke ist unbedingt darauf zu achten, dass die Kommunikation ausschließlich verschlüsselt und authentifiziert stattfindet.
Dead-End-Server
Da alle Verbindungen zum DGS (DataGatewayServer - Kommunikations-/Schnittstellen-Software) eingehend sind, kann als zusätzliche Sicherheitsmaßnahme der DGS auf einem separaten Server installiert werden, bei welchem alle ausgehenden Verbindungen via Firewall blockiert werden.
Authentifizierung
Authentifizierungs-Mechanismen können nur als "sicher" bezeichnet werden, wenn diese in Kombination mit anderen Sicherheits-Mechanismen wie HTTPS/SSL genutzt werden. Die Verschlüsselung ist mittels HTTPS unter Verwendung von TLSv1.2 oder TLSv1.3 (sofern vom Client unterstützt) möglich.
Die folgenden Authentifizierungs-Optionen beziehen sich ausschließlich auf die RESTv2 Schnittstelle
Basic Authentication
Die Basisauthentifizierung ist ein einfaches Authentifizierungsschema, welches in das HTTP-Protokoll integriert ist. Der Client sendet in jeder HTTP-Anfrage den Autorisierungsheader, welcher Benutzername und Passwort enthält.
Der Autorisierungsheader lautet Authorization und beinhaltet den Benutzer und Passwort Base64 codiert im Format - Basic <Benutzer>:<Passwort>.
Die Benutzerverwaltung erfolgt im DataGatewayServer. Dort können neue Benutzer angelegt und gelöscht werden.
Hinweis: Mit zunehmender Anzahl von gültigen Benutzern steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird.
Beispiele Autorisierungsheader:
In diesem Beispiel wird der Benutzer heidler mit dem Passwort Wolfschlugen verwendet.
POST <ENDPOINT> HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Basic aGVpZGxlcjpXb2xmc2NobHVnZW4=
Cache-Control: no-cache
Sollte die Authentifizierung aufgrund von falschem Benutzer oder Passwort fehlschlagen, so wird der HTTP-Code 401 Unauthorized mit der Fehlermeldung "Unauthorized acces" im Body quittiert.
HTTP/1.1 401 Unauthorized
Www-authenticate: Basic realm="Restricted Area"
Date: Mon, 26 Feb 2024 09:00:44 GMT
Content-type: application/json
Content-length: 19
Unauthorized accessDigest Access Authentication
HTTP Digest Access Authentication ist ein Authentifizierungsmechanismus, der in das HTTP-Protokoll integriert ist und dazu dient, die Sicherheit von Webanwendungen zu erhöhen. Im Gegensatz zur einfachen Basisauthentifizierung überträgt Digest Access Authentication keine Benutzernamen und Passwörter im Klartext, sondern verwendet kryptografisch sichere Methoden.
Bei der Digest-Authentifizierung sendet der Client eine Anfrage an den Server, der daraufhin eine "Nonce" (eine einmalige Zufallszahl) zurückgibt. Der Client kombiniert diese Nonce mit Benutzername, Passwort, Anfrage-Methode und URI und erstellt einen "Digest" (Prüfzusammenstellung). Dieser Digest wird dann an den Server gesendet.
Der Server kann den Digest überprüfen, indem er denselben Algorithmus auf der Serverseite anwendet und die berechneten Werte vergleicht. Da der Digest mit Hilfe der Nonce und kryptografisch sicheren Techniken erstellt wird, schützt die Digest-Authentifizierung effektiv vor Angriffen wie Passwortdiebstahl und MitM-Angriffen.
Die Benutzerverwaltung erfolgt im DataGatewayServer. Dort können neue Benutzer angelegt und gelöscht werden.
Hinweis: Mit zunehmender Anzahl von gültigen Benutzern steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird.
Beispiele:
In der erstanfrage wird im Header keine Autorisierung geliefert, da vom Server zuerst die nonce abgefragt werden muss. In der Rückmeldung befindet sich dann die nonce zusammen mit weiteren Informationen im HTTP-Header Www-authenticate.
Diese Anfrage wird mit dem HTTP-Code 401 Unauthorized und der Fehlermeldung "Authentication required!" im Body quittiert.
HTTP/1.1 401 Unauthorized
Www-authenticate: Digest realm="Restricted Area",qop="auth",nonce="079ae550-11c1-40bf-9ee9-7cce5f1dd70e",opaque="opaque"
Date: Mon, 26 Feb 2024 10:21:41 GMT
Content-type: application/json
Content-length: 24
Authentication required!
Nachdem die nonce aus der ersten Anfrage extrahiert und der "Digest" erstellt worden ist, erfolgt die Anfrage für die Verarbeitung mit dem HTTP-Header Authorization.
POST <ENDPOINT> HTTP/1.1
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache
Authorization: Digest username="<BENUTZER>", realm="Restricted Area", nonce="079ae550-11c1-40bf-9ee9-7cce5f1dd70e", uri="<ENDPOINT>", algorithm="MD5", qop=auth, nc=00000001, cnonce="PoYGQC6K", response="ce3fb921e353290142e34ac886694a4c", opaque="opaque"
Bei einer ungültigen Autorisierung (Verwendung vom HTTP-Header Authorization) wird der HTTP-Code 401 Unauthorized mit der Fehlermeldung "client credentials invalid!" im Body zurück gemeldet.
HTTP/1.1 401 Unauthorized
Date: Mon, 26 Feb 2024 10:45:40 GMT
Content-type: application/json
Content-length: 27
client credentials invalid!API Keys
Die API-Key-Authentifizierung ist eine einfache Methode zur Sicherung von API-Zugriffen. Bei dieser Authentifizierungsmethode erhält der Benutzer / Hostsystem einmalig einen eindeutigen API-Schlüssel (API-Key). Dieser Schlüssel muss dann bei jeder API-Anfrage im Header mit gesendet werden.
Der Server überprüft den empfangenen API-Key, um sicherzustellen, dass die Anfrage von einem autorisierten Benutzer oder einer autorisierten Anwendung stammt.
Der API-Key muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, diesen regelmäßig zu zu aktualisieren, um die Sicherheit zu gewährleisten.
Der API-Key wird im DataGatewayServer verwaltet. Dort kann ein neuer Key generiert werden. Es können mehrere API-Keys generiert werden.
Hinweis: Mit zunehmender Anzahl von gültigen API-Keys steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird.
Beispiele:
In diesem Beispiel wird der API-Key apikey_heidler verwendet.
POST <ENDPOINT> HTTP/1.1
Content-Type: application/json
Accept: application/json
x-api-key: apikey_heidler
Cache-Control: no-cache
Bei einem falschen API-Key wird der HTTP-Code 401 Unauthorized mit der Fehlermeldung "api key invalid!" im Body zurück gemeldet.
HTTP/1.1 401 Unauthorized
Date: Mon, 26 Feb 2024 09:46:30 GMT
Content-type: application/json
Content-length: 16
api key invalid!OAuth 2.0
Client Credentials
OAuth 2.0 Client Credentials ist eine Authentifizierungs-Methode im OAuth 2.0-Protokoll, die es einer Anwendung ermöglicht, sich beim Authorization Server (Authentifizierungsserver) zu authentifizieren. Dies ist besonders nützlich für den Zugriff von Anwendungen auf APIs ohne Benutzerbeteiligung und eignet sich gut für server-seitige Kommunikation zwischen Diensten.
Das ERP wird am Server registriert und erhält eine eindeutige Client-ID und ein Client Secret.
Inital wird dann von dem ERP eine HTTP-POST-Anfrage an den Authorization Server gesendet, welche die Client-Anmeldeinformationen (Client ID und Client Secret) beinhaltet. Im Response wird ein Access-Token und ein Refresh-Token zurück gemeldet.
Das ERP sendet nun für die Authentifizierung bei jeder Anfrage das Access-Token im Authorization Header der HTTP-Anfragen mit. Wenn das Access-Token abgelaufen ist, kann mit dem Refresh-Token ein neuer Access-Token angefragt werden. Im Falle einer mehrfachen Nutzung eines Refresh-Tokens werden automatisch alle Refresh-Tokens und Access-Tokens gesperrt.
Das Client Secret muss sicher aufbewahrt werden, um unbefugten Zugriff zu verhindern. Außerdem ist es wichtig, das Client Secret regelmäßig zu zu aktualisieren, um die Sicherheit weiter zu erhöhen.
Die Client-ID und Client-Secret werden im DataGatewayServer verwaltet. Dort können neue Client-IDs angelegt oder bestehende Client-IDs gelöscht werden.
Hinweis: Mit zunehmender Anzahl von gültigen Client-IDs steigt auch die Wahrscheinlichkeit, dass sich durch eine "Brute-Force-Attacke" unerlaubter Zugriff gewährt wird.
Beispiele:
Authorization Code
Diese Authentifizierungs-Methode ist ausschließlich über das Authentifzierungssystem IRIS Cloudsystem möglich.