Umfang

OAuth-Provider

Um eine präzisere Unterstützung für die OAuth-Bereichsverwaltung bereitzustellen, kann die Authentifizierungs-Benutzerregistrierungserweiterung URL den Bereichswert ändern.

Wenn Sie einen OAuth-Providerdefinieren, bieten die Erweiterungen für Erweiterte Bereichsüberprüfung die Flexibilität, zulässige Bereiche zu prüfen und zu überschreiben. Die optionalen Erweiterungen sind Anwendungsbereichsüberprüfung und Eignerbereichsprüfung.

Der Bereich, den die Anwendung schließlich empfängt, wird durch die Interaktionen bestimmt, die in den drei folgenden Absätzen beschrieben werden. Die Verarbeitung entspricht der Reihenfolge der Punkte 1, 2 und 3 in der folgenden Liste. Sie bietet drei verschiedene Möglichkeiten, um den Bereichswert zu überschreiben. In Abbildung 1 ist eine Übersicht über den Prozess dargestellt.

1. Nachdem die Anwendung erfolgreich authentifiziert wurde und wenn OAuth Native Provider > Erweiterte Bereichsüberprüfung > Überprüfung des Anwendungsbereichs konfiguriert ist, führt API Connect einen Aufruf aus, um eine zusätzliche Verifizierung zuzulassen, und verwendet den Inhalt von x-selected-scope , um den Bereichswert zu überschreiben, der ursprünglich von der Anwendung angefordert wurde. Wenn die Anwendungsbereichsüberprüfung aktiviert ist, muss der HTTP-Antwortheader x-selected-scope vorhanden sein oder der Aufruf schlägt fehl.
2. Wenn der OAuth Native-Anbieter > Benutzersicherheit > Authentifizierung so konfiguriert ist, dass Anwendungsbenutzer mithilfe einer Authentifizierung URL authentifiziert werden, dann führt API Connect einen Aufruf durch, wie in der Authentifizierung URL Benutzerregistrierung dokumentiert. Wenn der AntwortcodeHTTP 200Wenn der Antwortheader x-selected-scope vorhanden ist, wird der Wert, der in x-selected-scope konfiguriert ist, als neuer Bereichswert verwendet. Er überschreibt sowohl das, was die Anwendung bereits angefordert hat, als auch das, was in der in Absatz 1 beschriebenen Überprüfung des Anwendungsbereichs angegeben wurde. Im Antwortheader ist x-selected-scope ein optionales Element.
3. Nachdem der Benutzer erfolgreich authentifiziert wurde und OAuth Native Provider > Erweiterte Bereichsprüfung > Bereichsprüfung des Besitzers aktiviert und mit einer gültigen URL konfiguriert ist, API Connect macht einen Anruf, um den Inhalt von x-selected-scope um den Umfangswert zu verfeinern. Wenn die Eignerbereichsüberprüfung aktiviert ist, muss der HTTP-Antwortheader x-selected-scope vorhanden sein oder der Aufruf schlägt fehl.

   

Die endgültige Bereichsberechtigung, die vom Zugriffstoken erteilt wird, ist das Ergebnis des in den Elementen 1, 2 und 3 beschriebenen Ablaufs. Abbildung 2 zeigt eine detailliertere Ansicht des Transaktionsablaufs mit Beispielen, die zeigen, wenn x-selected-scope einen neuen Bereichswert bereitstellt.

Konsumenten-API-Durchsetzung

GET /getaccount
HTTP/1.1
Host: server.example.com
X-IBM-Client-Id: 8888-8888-8888
Authorization: Bearer AAEkNjVkOWIyYjgtOWY5ZS00YWQwLWIyYzktZ

secure-banking.yaml

securityDefinitions:
   scope-only:
    type: oauth2
    description: ''
    flow: implicit
    authorizationUrl: ''
    scopes:
      checking: 'Checking Account'
      saving: 'Saving Account'
      mutual: 'Mutual Fund Account'
security:
  - scope-only:
      - checking
  - scope-only:
      - saving
      - mutual

Administratoren können eine zusätzliche Bereichsprüfung aktivieren, indem sie die Eigenschaft "Erweiterte Bereichsprüfung" der Verbraucher-API konfigurieren. URL wird zu x-scopeValidate , wie im folgenden OpenAPI dateibeispiel.

securityDefinitions:
  advanced-scope-only:
    type: oauth2
    description: ''
    flow: implicit
    authorizationUrl: ''
    scopes:
      checking: 'Checking Account'
      saving: 'Saving Account'
      mutual: 'Mutual Fund Account'
    x-scopeValidate:
      url: 'https://advanced-scope-check.bk.com/validate-scope'
      tls-profile: 'ssl-client'

Nachdem das Zugriffstoken erfolgreich anhand einer Bereichsanforderung überprüft wurde, wird eine HTTP POST -Anforderung an den Endpunkt x-scopeValidate ähnlich dem folgenden Beispiel abgesetzt. AntwortcodeHTTP 200vom Endpunkt gibt einen Erfolg an. Jeder andere Antwortcode oder ein Verbindungsfehler wird so behandelt, als ob das Token nicht die erforderliche Berechtigung für den Zugriff auf die Ressource enthielte.

     POST /validate-scope?app-name=..&appid=..&org=..&orgid=..&catalog=..&catalogid=..&transid=.. 
HTTP/1.1
     Host: advanced-scope-check.bk.com
     Content-Type: application/json

   {"context-root" : checking,
    "resource" : accountinfo,
    "method" : GET,
    "api-scope-required" : [jointaccount],
    "access_token" : {"client_id" : "2cd71759-1003-4a1e-becb-0474d73455f3",
                      "not_after" : 174364070,
                      "not_after_text" : "2017-07-11T02:27:50Z",
                      "not_before" : 174360470,
                      "not_before_text" : "2017-07-11T01:27:50Z",
                      "grant_type" : "code",
                      "consented_on" : 1499736470,
                      "consented_on_text" : "2059-07-11T01:27:50Z",
                      "resource_owner" : "cn=spoon,email=spoon@poon.com",
                      "scope" : "jointaccount mutual",
                      "miscinfo" : "[r:gateway]"
                    }
}

     HTTP/1.1 200 OK
     Cache-Control: no-store
     Pragma: no-cache
     X-Custom-For-Assemble-Process: audit

Jeder HTTP-Antwortheader, der mit "x-" beginnt, wird als Kontextvariable oauth.advanced-consent beibehalten. Basierend auf der Beispielantwort auf erfolgreiche Ausführung wird X-Custom-For-Assemble-Process: auditoauth.advanced-consent.x-custom-for-assemble-processund kann im Assemblierungsschritt aufgerufen werden.

Sie können optional zusätzliche Felder zur Validierung verwenden:

Anforderungsheader

Definiert den regulären Ausdruck, der mit den Anforderungsheadern abgeglichen werden soll. Übereinstimmende Header werden in die Anforderung an den Endpunkt für die erweiterte Bereichsprüfung eingeschlossen.

Antwortkontextvariable

Definiert den regulären Ausdruck, der mit den Antwortheadern abgeglichen werden soll. Übereinstimmende Header werden als Kontextvariablen im Format oauth.advanced-consent.* gespeichert.