Product-apim: Unterstützung der Basisauthentifizierung für Abonnenten

Das neu veröffentlichte APIM 3.0.0 unterstützt Basic Auth. Wir verwenden es derzeit in unserer Umgebung.

Ja für Back-End-Endpunkte. Für Api konnte ich die Option nicht finden.

API Publisher -> Laufzeitkonfigurationen -> Sicherheit auf Anwendungsebene

@Tomas-Mrazek richtig, jetzt unterstützen wir auch die Basic Authentication für API-Clients. Sie können die Option Basic unter der Sicherheit auf Anwendungsebene wie oben gezeigt aktivieren. Dadurch können API-Nutzer diese API mit ihrer Benutzernamen-Passwort-Kombination aufrufen.

Ok, sieht so aus, als hätte ich an der gleichen Stelle gesucht. Habe es gerade getestet und es funktioniert.

Dies wirft weitere Fragen auf.

Wie funktionieren Abonnements mit Basic Auth? Scheint, als ob jeder Benutzer unabhängig von Abonnements jede beliebige API aufrufen kann? Gibt es eine Möglichkeit, Benutzer bestimmten Anwendungen zuzuordnen, sodass sie nur die API aufrufen können, für die die Anwendung abonniert ist?

Wenn sowohl Prod als auch Sandbox dasselbe Gateway verwenden, wie wird dann bestimmt, welches bei der grundlegenden Authentifizierung aufgerufen wird?

Diese beiden Fragen müssten nicht beantwortet werden, wenn wir in der Basisauthentifizierung den Anwendungsschlüssel und das Anwendungsgeheimnis anstelle von Benutzername und Kennwort verwenden würden.

Vielleicht fehlt mir etwas, daher wäre es gut, wenn Sie mich auf die Dokumentation hinweisen könnten.

Wie funktionieren Abonnements mit Basic Auth? Scheint, als ob jeder Benutzer unabhängig von Abonnements jede beliebige API aufrufen kann? Gibt es eine Möglichkeit, Benutzer bestimmten Anwendungen zuzuordnen, sodass sie nur die API aufrufen können, für die die Anwendung abonniert ist?

Nein, es sollte genauso funktionieren wie mit dem oauth2-Token. Nur abonnierte Benutzer können API aufrufen, egal ob über Token oder Basic Auth.

Sie können keine Benutzer zu Anwendungen zuweisen, da dies umgekehrt funktioniert - Anwendungen gehören dem Benutzer. Wenn Sie eine genauere Kontrolle wünschen, erstellen Sie Rollen in der /carbon-Konsole und weisen Sie sie den Benutzern zu. Gehen Sie im API-Publisher zu den API-Einstellungen und ändern Sie die Sichtbarkeit im Devportal auf eine bestimmte Rolle. Erstellen Sie dann Bereiche mit einer bestimmten Rolle für jede Ressource, weisen Sie diesen Bereich der Ressource zu, aktivieren Sie die Sicherheit. Abonnierte Benutzer können die API aufrufen, aber ohne dass Sie dem Benutzer eine Rolle zuweisen, können sie keine geschützten Ressourcen aufrufen.

Wenn sowohl Prod als auch Sandbox dasselbe Gateway verwenden, wie wird dann bestimmt, welches bei der grundlegenden Authentifizierung aufgerufen wird?

Gute Frage. Ich kenne die Antwort nicht.

Mit Consumer Key und Secret würde das übrigens nicht funktionieren. Der Endpunkt wird während der /token-Generierung AFAIK angegeben.

Hallo @Tomas-Mrazek und @tmkasun , genau das ist jetzt mein Problem mit der Basic-Authentifizierung. Lassen Sie mich versuchen, meine Gedanken zur Authentifizierung zusammenzufassen:

OAuth2 - wir abonnieren eine App für eine API. Anhand von Schlüssel und Geheimnis kennen wir die App und die Umgebung. Damit die App API verwenden kann, müssen wir sie nur abonnieren. Dann kann jeder Benutzer diese Api aufrufen, vorausgesetzt, er kennt Schlüssel und Geheimnis.

Statische API-Schlüssel - hier kennen wir den Schlüssel, und das gibt genügend Informationen, um zu wissen, welche Anwendung die API aufruft und welche Umgebung sie verwendet. Das Konzept, dass die App die API abonniert, um sie zu verwenden, gilt weiterhin. Wir müssen nur eine App für eine API abonnieren.

Standardauthentifizierung wie jetzt - ich nenne sie "benutzerbasierte Basisauthentifizierung". Es verzichtet vollständig auf das Konzept von App und Abonnement und erfordert die Verwendung eines anderen Konzepts (benutzerbasierte Berechtigungen) und verschiedener Tools wie die Verwendung von Carbon Admin anstelle von Publisher oder Store/DevPortal. Und es kann nicht zwischen Produktions- und Sandbox-Umgebung unterscheiden, wenn ein einziges Gateway für beide verwendet wird. Es erhöht auch die Komplexität bei der Einrichtung und Verwaltung. Jetzt reicht es nicht mehr, sich die Liste der abonnierten Apps anzusehen, man muss auch zum Carbon-Admin gehen und sich die Benutzer und Berechtigungen ansehen. Und wenn ich eine bestimmte App für eine API ratenbegrenzen möchte oder verschiedene Abonnementstufen habe, kann ich das für den Benutzer nicht tun.

Was ich als "richtige" Methode zur Unterstützung der Basisauthentifizierung ansehen würde, wäre Folgendes:

Basisauthentifizierung auf App-Ebene - Wir entfernen den Benutzer aus dem Konzept (wie bei statischen Schlüsseln) und verwenden stattdessen die Anwendungsauthentifizierung. Die Anwendung muss die API weiterhin abonnieren. Consumer Key und Consumer Secret werden als Basisauthentifizierungs-Anmeldeinformationen verwendet. Auf diese Weise behalten wir das App/Api-Abonnement-Konzept bei, können weiterhin die gleichen Tools wie für alles andere verwenden (Publisher / devPortal, kein Carbon Admin erforderlich) und wissen anhand der Schlüssel, welche App welche Api und welche Umgebung verwendet.

Wie man dorthin kommt?

Es gibt zwei Möglichkeiten. Ändern Sie entweder die aktuelle Basic-Implementierung in die oben vorgeschlagene, oder implementieren Sie eine neue namens "App Basic-Authentifizierung".
Es gibt auch eine dritte Option, um sowohl Benutzer/Pass als auch Schlüssel/Geheimnis in der bestehenden Basis-Authentifizierung zu unterstützen, aber das ist die schmutzigste.

Eine einfache Auth-Implementierung reicht nicht aus. Zum Beispiel können Sie die API-Sichtbarkeit auf Devportal basierend auf Rollen einschränken -> die erstellt und mit dem Benutzer über die Carbon-Konsole verknüpft werden müssen.

Hallo @Tomas-Mrazek und @markokocic
Vielen Dank für Ihre Vorschläge. Bitte finden Sie meine Antworten inline.

Wie funktionieren Abonnements mit Basic Auth? Scheint, als ob jeder Benutzer unabhängig von Abonnements jede beliebige API aufrufen kann? Gibt es eine Möglichkeit, Benutzer bestimmten Anwendungen zuzuordnen, sodass sie nur die API aufrufen können, für die die Anwendung abonniert ist?

Für die grundlegende Authentifizierungsunterstützung für Clientanforderungen müssen keine Abonnements vorhanden sein. Wenn ein API-Ersteller die Unterstützung der Basisauthentifizierung für eine bestimmte API aktiviert hat, kann diese API aufgerufen werden, ohne diese API zu abonnieren (nach Anwendung).
und @markokocic ja, wie das Abonnement funktioniert, ist An Application subscribed to an API .

Außerdem mit Baisc-Authentifizierung:
du bekommst noch:

• Drosselung auf Ressourcen- oder API-Ebene
• Validierung des Ressourcenbereichs

du bekommst nicht:

• Drosselung auf Abonnementebene
• Differenzierung in der Produktions- und Sandbox-Umgebung

Wenn sowohl Prod als auch Sandbox dasselbe Gateway verwenden, wie wird dann bestimmt, welches bei der grundlegenden Authentifizierung aufgerufen wird?

Ja, wir konnten die Umgebung nicht nach Benutzername und Passwort unterscheiden. Wenn Sie die Basisauthentifizierung verwenden, haben Sie daher keine Möglichkeit, die Umgebung auszuwählen. Der Produktionsendpunkt wird verwendet.

@Tomas-Mrazek

Der Endpunkt wird während der /token-Generierung AFAIK angegeben.

Nein, Endpunkte (Prod & Sandbox) werden vom API-Ersteller beim Erstellen der API definiert. API-Konsumenten können eine Rückruf-URL für eine Anwendung bereitstellen, wenn sie umleitungsbasierte Gewährungstypen verwenden möchten (d. h. implizit).

@markokocic bezüglich

Basic-Authentifizierung auf App-Ebene

Dies ist auch mit der aktuellen Implementierung möglich. Sie können den Gewährungstyp für die Clientanmeldeinformationen verwenden, um ein Tokenpaar im Namen des Anwendungsbesitzers abzurufen.

Basic-Authentifizierung auf App-Ebene

Dies ist auch mit der aktuellen Implementierung möglich. Sie können den Gewährungstyp für die Clientanmeldeinformationen verwenden, um ein Tokenpaar im Namen des Anwendungsbesitzers abzurufen.

@tmkasun
Ja, es ist möglich, die Standardauthentifizierung zu verwenden, um Token mithilfe von Clientanmeldeinformationen zu generieren. Sie verwenden so etwas:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Um die API verwenden zu können, muss Ihr Verbraucher jedoch weiterhin in der Lage sein:

• Generieren Sie das Token mit der obigen Methode
• setze es als http "Authorization" Header mit Bearer und Token für die eigentliche API-Anfrage
• Kümmere dich schließlich um den Ablauf und die Aktualisierung des Tokens

Es ist in Ordnung, wenn ein Programmierer Ihren Verbraucher programmiert oder Sie einen Anbieter haben, der dies tun kann. Wie beschrieben, tritt das Problem bei vielen Legacy-Unternehmensclients auf, die nicht anpassbar sind. Wenn Sie beispielsweise in SAP einen externen Service nutzen möchten, können Sie nur die URL und optional den Benutzernamen und das Kennwort für die Basisauthentifizierung festlegen. Dort haben Sie keine Möglichkeit, Token abzurufen oder benutzerdefinierte Header festzulegen.

Was ich oben als Basisauthentifizierung auf App-Ebene beschrieben habe, ist tatsächlich die Möglichkeit, den Schritt der Tokengenerierung zu überspringen und die Basisauthentifizierung basierend auf den Client-Anmeldeinformationen direkt zu verwenden, um die API aufzurufen.

Etwas wie:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Dies würde es mir ermöglichen, immer noch das gleiche App-to-API-Abonnementmodell auf einheitliche Weise zu verwenden, ohne Benutzer erstellen, einrichten und verwalten zu müssen.

Da der Standardauthentifizierungsstandard die Möglichkeit bietet, den Autorisierungsheader als Teil der URL einzuschließen, können wir als weiterer Vorteil sogar ältere Verbraucher mit etwas wie diesem unterstützen:

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

BEARBEITEN: Jetzt, wo ich darüber nachdenke, wäre der eindeutigere Name vielleicht die auf Client-Anmeldeinformationen basierende Basisauthentifizierung für die API.