REST-Client: Anmeldevarianten

Diese Seite beschreibt die verfügbaren Anmeldevarianten des REST-Client-Plug-ins. Welche Variante verwendet werden muss, richtet sich nach den Anforderungen des Zielsystems.

Die allgemeine Konfiguration des Plug-ins ist auf der Seite REST-Client beschrieben.

Übersicht

Anmeldung	Beschreibung	Typischer Einsatz
None	Es wird keine Anmeldung durch das Plug-in durchgeführt.	Für öffentlich erreichbare Endpunkte oder wenn Authentifizierungsinformationen im eigentlichen REST-Aufruf dynamisch übergeben werden.
HttpBasic	Das Plug-in sendet Benutzername und Passwort per HTTP Basic Authentication.	Für RESTful Webservices mit klassischer Benutzer-/Passwort-Anmeldung über den HTTP-Header Authorization.
Jwt	Das Plug-in sendet ein JSON Web Token zur Authentifizierung.	Wenn das Zielsystem direkt ein JWT erwartet.
OAuth1	Das Plug-in verwendet OAuth 1 zur Anmeldung.	Für RESTful Webservices, die noch OAuth 1 verlangen.
OAuth2-RequestHeader	Das Plug-in sendet den OAuth-2-Token im HTTP-Header.	Wenn das Zielsystem einen Bearer-Token im Header erwartet.
OAuth2-UriQueryParameter	Das Plug-in übergibt den OAuth-2-Token als Query-Parameter in der URL.	Wenn das Zielsystem den Token explizit in der URL erwartet.
Negotiate (process identity)	Das Plug-in verwendet die Identität des laufenden Prozesses für die Anmeldung.	Für integrierte Windows-Authentifizierung, wenn der RESTful Webservice diese unterstützt.
Digest	Das Plug-in verwendet HTTP Digest Authentication.	Für RESTful Webservices, die Digest Authentication verlangen.

Hinweise zu den Varianten

None

Verwenden Sie None, wenn keine Anmeldung erforderlich ist oder wenn die Authentifizierungsinformationen nicht fest im Plug-in hinterlegt werden sollen.

Das ist insbesondere bei dynamisch ermittelten Tokens relevant.

HttpBasic

Diese Variante eignet sich für Zielsysteme, die feste Zugangsdaten aus Benutzername und Passwort erwarten.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Benutzername	Benutzername für die Anmeldung am RESTful Webservice.
Passwort	Passwort oder Passwortreferenz für den angegebenen Benutzer.

Jwt

Diese Variante eignet sich für Zielsysteme, die ein fest hinterlegtes JSON Web Token erwarten.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Access-Token	Fest im Plug-in hinterlegtes JSON Web Token. Diese Variante eignet sich nur, wenn das Token statisch hinterlegt werden kann.

Hinweis: Wenn das Token zuerst abgefragt oder regelmäßig erneuert werden muss, verwenden Sie statt Jwt die Option None und übergeben Sie den aktuellen Wert dynamisch im REST-Aufruf.

OAuth1

Diese Variante wird nur benötigt, wenn das Zielsystem noch OAuth 1 verwendet.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Signature-Method	Signaturverfahren für OAuth 1. Im gezeigten Beispiel wird HmacSha1 verwendet. Der geforderte Wert richtet sich nach dem Zielsystem und beeinflusst direkt, wie die OAuth-Signatur berechnet wird. Ein abweichender Wert führt dazu, dass die Anmeldung trotz korrekter Zugangsdaten abgelehnt werden kann.
Parameter-Handling	Legt fest, wie die OAuth-Parameter übertragen werden. Im gezeigten Beispiel werden sie über den HTTP-Authorization-Header gesendet. Welche Option zulässig ist, hängt von der Implementierung des Zielsystems ab.
Signature-Treatment	Legt fest, wie die Signaturzeichen behandelt werden. Im gezeigten Beispiel wird Escaped verwendet. Diese Einstellung ist relevant, wenn Sonderzeichen oder URL-kodierte Zeichen in die Signaturberechnung eingehen.
Realm	Bezeichnet bei OAuth 1 den Gültigkeits- oder Schutzbereich der Anmeldung. Wenn der RESTful Webservice einen Realm vorgibt, muss dieser Wert entsprechend hinterlegt werden. Wird kein spezieller Realm verlangt, kann das Feld leer bleiben.

Hinweis: Wenn die OAuth-Anmeldedaten nicht fest hinterlegt werden sollen, sondern zuerst zur Laufzeit ermittelt werden müssen, verwenden Sie statt OAuth1 die Option None und übergeben Sie die benötigten Werte dynamisch im REST-Aufruf.

OAuth2-RequestHeader

Diese Variante eignet sich für Zielsysteme, die den OAuth-2-Token im HTTP-Header erwarten.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Access-Token	OAuth-2-Access-Token, das im Header mitgesendet wird.
Token-Type	Typbezeichner, der vor den Access-Token im Header gesetzt wird. In der Regel ist das Bearer, sodass ein Header wie Authorization: Bearer <Access-Token> entsteht. Der Wert ist nicht der Token selbst, sondern beschreibt dessen Übertragungsart im Header.

Hinweis: Wenn der Access-Token zuerst abgefragt oder regelmäßig erneuert werden muss, verwenden Sie statt OAuth2-RequestHeader die Option None und übergeben Sie den aktuellen Token dynamisch im REST-Aufruf. Ein Beispiel für diese Vorgehensweise ist auf der Seite Verbindung mit Bearer Token beschrieben.

OAuth2-UriQueryParameter

Diese Variante eignet sich für Zielsysteme, die den OAuth-2-Token als Query-Parameter erwarten.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Access-Token	OAuth-2-Access-Token, das als Query-Parameter an die URL angehängt wird.

Hinweis: Wenn der Access-Token zuerst abgefragt oder regelmäßig erneuert werden muss, verwenden Sie statt OAuth2-UriQueryParameter die Option None und übergeben Sie den aktuellen Wert dynamisch im REST-Aufruf.

Negotiate (process identity)

Bei dieser Variante authentifiziert sich das Plug-in mit der Identität des Prozesses, unter dem der OPC Router ausgeführt wird. Diese Variante blendet keine zusätzlichen Eigenschaften ein. Die Anmeldung erfolgt über die Prozessidentität, unter der der OPC Router ausgeführt wird. Welche Identität tatsächlich verwendet wird, hängt also direkt davon ab, unter welchem Benutzerkonto oder Dienstkonto der OPC Router läuft.

Digest

Diese Variante eignet sich für Zielsysteme, die HTTP Digest Authentication verlangen.

Zusätzliche Eigenschaften:

Eigenschaft	Beschreibung
Username	Benutzername für die Digest-Anmeldung am RESTful Webservice.
Password	Passwort oder Passwortreferenz für den angegebenen Benutzer.

Dynamische OAuth-Anmeldedaten

Die Hinweise zur dynamischen Übergabe stehen direkt in den betroffenen Variantenabschnitten. Grundsätzlich gilt: Wenn OAuth-Anmeldedaten oder Tokens zuerst abgefragt oder regelmäßig erneuert werden müssen, verwenden Sie im REST-Client-Plug-in die Option None und übergeben Sie die aktuellen Werte im REST-Aufruf dynamisch.

Ein durchgängiges Beispiel für dieses Vorgehen ist auf der Seite Verbindung mit Bearer Token beschrieben.

Das betrifft insbesondere folgende Varianten:

• OAuth1
• OAuth2-RequestHeader
• OAuth2-UriQueryParameter