Authentifizierungsoptionen
Bevor Sie einen Konnektor in Azure Logic Apps Power Automate, oder Power Apps verwenden, muss der Benutzer eine Verbindung herstellen, indem er sich beim Netzwerkdienst authentifiziert. Beim Erstellen eines benutzerdefinierten Konnektors können Sie festlegen, wie sich die Person, die den Konnektor verwendet, authentifiziert. Sie können den Authentifizierungstyp auf der Registerkarte Sicherheit im Assistenten für Onlinekonnektoren auswählen. Zusätzliche Informationen, die Sie angeben müssen, hängen vom ausgewählten Authentifizierungsschema ab.
Keine Authentifizierung
Wenn die Option Keine Authentifizierung ausgewählt ist, sind keine weiteren Informationen erforderlich. Der Benutzer benötigt keine Authentifizierung, um eine Verbindung zum benutzerdefinierten Konnektor herzustellen, und jeder anonyme Benutzer kann den Konnektor verwenden. Diese Option wird nur verwendet, wenn die API eine anonyme Verwendung zulässt.
Standardauthentifizierung
Die einfachste Art der Authentifizierung ist die Standardauthentifizierung, bei der der Benutzer den Benutzernamen und das Kennwort angibt, um die Verbindung herzustellen.
Die Werte, die Sie unter der Spalte Parameterbezeichnung eingeben, sind nicht der tatsächliche Benutzername oder das Kennwort, sie sind Beschriftungen für diese Felder, die dem Benutzer beim Erstellen der Verbindung angezeigt werden.
Im vorhergehenden Beispiel wird der Benutzer zur Eingabe von Benutzer und Kennwort aufgefordert, um eine Verbindung herzustellen. Sie sollten die Beschriftungen mit den Namen abgleichen, die von der API verwendet werden, um jemandem, der eine Verbindung erstellt, zu klären, welche Werte für diese Verbindung verwendet werden sollen.
Jede Serviceverbindung, die Standardauthentifizierung verwendet, muss ein sicheres HTTPS-Protokoll verwenden, um zu vermeiden, dass unverschlüsselte Anmeldeinformationen über das Kabel gesendet werden.
API-Schlüssel-Authentifizierung
API-Schlüssel ist ein beliebtes Authentifizierungsschema, das von Webdiensten verwendet wird. Zum Beispiel umfassen Microsoft Azure-Funktionen Code-Parameter als Teil der Standardvorlage.
Stellen Sie sicher, dass Sie die folgenden Werte definieren:
Parameterbeschreibung – Die Bezeichnung für die Benutzeraufforderung beim Erstellen einer neuen Verbindung.
Parametername – Der Name des Parameters, der bei jeder Serviceanforderung den Schlüsselwert enthält.
Ort des Parameters – Ermöglicht Entwicklern die Option, den API-Schlüssel im Anforderungsheader oder in der Abfragezeichenfolge zu senden, wenn sie den zugrunde liegenden Service aufrufen.
Im vorherigen Beispiel wird dem Benutzer, der eine neue Verbindung erstellt, die folgende Eingabeaufforderung angezeigt.
Der angegebene Wert wird als benutzerdefinierter X-API-Key-Anforderungsheader an den zugrunde liegenden Service gesendet.
Die Standardvorlage für Azure-Funktionen kann Code als Parameternamen verwenden und ihn dann als Teil der Abfrage senden, indem Sie den Parameterspeicherort auf Abfrage festlegen, sodass die Service-URL ähnlich ist wie:
https://functionurl.azurewebsites.net?code=user-supplied-code/
Ähnlich wie bei der Standardauthentifizierung empfehlen wir Ihnen, das API-Schlüssel-Authentifizierungsschema nur mit HTTPS-Protokoll zu verwenden, um zu vermeiden, dass die Schlüssel unverschlüsselt gesendet werden.
OAuth 2.0-Authentifizierung
Das OAuth 2.0-Authentifizierungsschema ist nur für Onlinekonnektoren verfügbar. Neben der Unterstützung von Generic OAuth 2.0 bietet die Plattform Implementierungen für bestimmte Dienste, einschließlich Microsoft Entra ID, GitHub, Microsoft-Konto und weitere. Wenn vorgefertigte Vorlagen für Identitätsanbieter ausgewählt sind, füllen Sie viele der für OAuth 2.0 erforderlichen Felder aus, wobei anbieterspezifische Werte die Bereitstellung reduzieren.
Zusätzliche Informationen, die gesammelt werden, hängen vom Identitätsanbieter ab. Der Generic OAuth 2.0-Anbieter benötigt die folgenden Parameter.
| Parameter | Beschreibung |
|---|---|
| Client-ID | OAuth-App-ID im Zielsystem, manuell eingegeben oder vom Anbieter bei der Registrierung der App generiert. |
| Geheimer Clientschlüssel | Geheimschlüssel im Zusammenhang mit der vom Anbieter generierten OAuth-App. Die meisten Anbieter können auch bestehende Geheimnisse widerrufen und neue herausgeben. |
| Autorisierungs-URL | URL, mit der der Benutzer angemeldet und die Anwendung autorisiert wird, zum Beispiel: https://www.facebook.com/v9.0/dialog/oauth oder https://login.salesforce.com/services/oauth2/authorize. |
| Token-URL | URL zum Abrufen eines Tokens, nachdem die App vom Benutzer autorisiert wurde, zum Beispiel: https://graph.facebook.com/v9.0/oauth/access_token oder https://mycompany.salesforce.com/mycompany.salesforce.com. |
| URL aktualisieren | URL zum Abrufen eines neuen Tokens mithilfe eines Aktualisierungstokens nach Ablauf des ursprünglichen Tokens. Diese URL entspricht normalerweise der Token-URL für die meisten Dienste. |
| Umfang | Zeichenfolge, die die Berechtigungen darstellt, die Sie vom Benutzer einholen. Lassen Sie diesen Parameter leer oder lesen Sie die Anbieterdokumentation, um den Umfang der Berechtigung anzugeben, den Ihre App benötigt. |
Stellen Sie sicher, dass Sie den Konnektor beim Identitätsanbieter als Clientanwendung registrieren. Spezifische Registrierungsdetails sind anbieterabhängig und werden vom Identitätsanbieter dokumentiert. Zum Beispiel würde ein Entwickler eine Facebook-App mit ihren Entwicklungstools erstellen, um sich mit Facebook zu authentifizieren. Weil die Parameter Client-ID und Geheimer Clientschlüssel Teil der OAuth 2.0-Spezifikationen sind, werden sie von allen OAuth 2.0-Identitätsanbietern im Rahmen der App-Registrierung bereitgestellt. Ein Wert, der in der App-Registrierung enthalten sein muss, ist Umleitungs-URL. Dieser Wert in der Konnektorkonfiguration ist zunächst leer, wird jedoch verfügbar, wenn die Konfiguration gespeichert wird. Er kann dann kopiert und mit der Konnektorregistrierung beim Identitätsanbieter gespeichert werden.
Die meisten spezifischen Anbieter benötigen nur die Client-ID, den geheimen Clientschlüssel und den optionalen Bereich, da alle URLs für einen bestimmten Dienst vordefiniert sind.
Nachdem der Konnektor veröffentlicht und den Benutzern zur Verfügung gestellt wurde, werden sie aufgefordert, ihre Anmeldeinformationen für die Anmeldung beim Dienst während des Verbindungserstellungsprozesses einzugeben. Diese Anmeldeinformationen werden von der Anwendung verwendet, um ein Autorisierungstoken zu erhalten. Für jede Anforderung wird dieses Autorisierungstoken über den Standardautorisierungsheader an Ihren Dienst gesendet.
Das Autorisierungstoken ist von kurzer Dauer, und die Konnektorlaufzeit verwendet den Aktualisierungsprozess zum Erneuern, sodass Benutzer des Konnektors nicht am Aktualisierungsprozess beteiligt sind.
Windows-Authentifizierung
Die Windows-Authentifizierungsoption ist nur für Verbindungen verfügbar, die ein lokales Datengateway verwenden, wenn das Kontrollkästchen Verbindung über ein lokales Datengateway herstellen auf die Registerkarte Allgemein eingestellt ist. Für das Windows-Authentifizierungsschema sind keine zusätzlichen Informationen erforderlich.
Wenn eine neue Verbindung erstellt wird, muss der Benutzer Windows-Anmeldeinformationen für den Dienst angeben und dann eines der installierten lokalen Gateways auswählen.
Die OpenAPI-Spezifikation, die von der Plattform verwendet wird, umfasst beides, Definitionen für API-Schlüssel und für die grundlegende Authentifizierung. Sie können sie auch direkt online mit dem Swagger-Editor ändern. Andere Authentifizierungsschemas speichern Authentifizierungsinformationen separat als erweiterte Eigenschaften des Konnektors. Diese Informationen sind zwar nicht für die direkte Online-Bearbeitung von Quellen verfügbar, Sie können sie jedoch mithilfe vom paconn-Tool ändern. Die Befehlszeilenschnittstelle (Command Line Interface, CLI) ermöglicht die Skripterstellung des Konnektor-Bereitstellungsprozesses, wenn eine automatisierte Bereitstellung erforderlich ist.
Benutzerdefinierte Konnektoren unterstützen mehrere Authentifizierungsschemas, um den Anforderungen für den Zugriff auf sichere REST-API-Services gerecht zu werden. Wenn API-Dienste innerhalb einer Azure AD-Umgebung bereitgestellt werden, bietet die Infrastruktur des Konnektors weitere Vorteile. Sie erfahren weitere Azure AD-Einzelheiten in der nächsten Lerneinheit.