Diese Seite wurde von der Cloud Translation API übersetzt.

Zugriff auf OAuth 2.0-Tokens nach Nutzer-ID und App-ID aktivieren

Edge for Private Cloud Version 4.17.01

In diesem Dokument wird beschrieben, wie Sie das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Endnutzer-ID, Anwendungs-ID oder beidem aktivieren.

Anwendungs-IDs werden einem OAuth-Zugriffstoken automatisch hinzugefügt. Nachdem Sie das folgende Verfahren verwendet haben, um den Tokenzugriff für eine Organisation zu aktivieren, können Sie nach App-ID auf Tokens zugreifen.

Zum Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Endnutzer-ID muss eine Endnutzer-ID im Zugriffstoken vorhanden sein. Im folgenden Verfahren wird beschrieben, wie Sie einem vorhandenen oder neuen Token eine Endnutzer-ID hinzufügen.

Ein von Edge generiertes OAuth 2.0-Zugriffstoken hat standardmäßig das folgende Format:

{
  "issued_at" : "1421847736581",
  "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
  "scope" : "READ",
  "status" : "approved",
  "api_product_list" : "[PremiumWeatherAPI]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
  "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
  "organization_name" : "myorg",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Wichtige Hinweise:

Das Feld application_name enthält die UUID der Anwendung, die mit dem Token verknüpft ist. Wenn Sie das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach App-ID aktivieren, gilt dies für die von Ihnen verwendete App-ID.
Das Feld access_token enthält den Wert des OAuth 2.0-Zugriffstokens.

Wenn Sie OAuth 2.0-Zugriffstokens nach Endnutzer-ID abrufen und widerrufen möchten, müssen Sie die OAuth 2.0-Richtlinie so konfigurieren, dass die Nutzer-ID wie unten beschrieben im Token enthalten ist.

Die Endnutzer-ID ist der String, der in Edge als Entwickler-ID verwendet wird, nicht die E-Mail-Adresse des Entwicklers. Sie können die ID des Entwicklers anhand seiner E-Mail-Adresse ermitteln, indem Sie den API-Aufruf „Get Developer“ verwenden.

Wenn Sie Edge so konfiguriert haben, dass die Endnutzer-ID im Token enthalten ist, wird sie wie unten dargestellt als Feld „app_enduser“ angezeigt:

{
  "issued_at" : "1421847736581",
  "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
  "scope" : "READ",
  "app_enduser" : "6ZG094fgnjNf02EK",
  "status" : "approved",
  "api_product_list" : "[PremiumWeatherAPI]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
  "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
  "organization_name" : "myorg",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

APIs zum Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Nutzer-ID und App-ID

Mit den folgenden APIs können Sie auf OAuth-Tokens nach Benutzer-ID, App-ID oder beidem zugreifen:

Verfahren zum Aktivieren des Tokenzugriffs

Mit dem folgenden Verfahren können Sie das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens anhand der Endnutzer-ID und Anwendungs-ID aktivieren.

Schritt 1: Unterstützung für den Tokenzugriff für eine Organisation aktivieren

Sie müssen den Tokenzugriff für jede Organisation separat aktivieren. Rufen Sie die folgende PUT-API für jede Organisation auf, für die Sie das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Endnutzer-ID oder App-ID aktivieren möchten.

Der Nutzer, der den folgenden Aufruf ausführt, muss die Rolle orgadmin oder opsadmin für die Organisation haben. Ersetzen Sie die Werte in {curly braces} durch Ihre organisationsspezifischen Werte:

> curl -H "Content-type:text/xml" -X POST \
  https://<ms-ip>:8080/v1/organizations/{org_name} \
  -d '<Organization name="{org_name}">
      <Properties>
        <Property name="features.isOAuthRevokeEnabled">true</Property>
        <Property name="features.isOAuth2TokenSearchEnabled">true</Property>
      </Properties>
    </Organization>' \ 
  -u {userEmail}:{mypassword}

Schritt 2: Berechtigungen für die Rolle „opsadmin“ in der Organisation festlegen

Nur die Rollen orgadmin und opsadmin in einer Organisation sollten Berechtigungen zum Abrufen (HTTP GET) und Widerrufen (HTTP PUT) von OAuth 2.0-Tokens basierend auf der Nutzer-ID oder App-ID erhalten. Um den Zugriff zu steuern, legen Sie Get- und Put-Berechtigungen für die Ressource „/oauth2“ für eine Organisation fest. Diese Ressource hat eine URL im folgenden Format:

https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2

Die Rolle orgadmin sollte bereits die erforderlichen Berechtigungen haben. Für die Rolle opsadmin für die Ressource /oauth2 sollten die Berechtigungen so aussehen:

<ResourcePermission path="/oauth2">
    <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
    </Permissions>
</ResourcePermission>

Mit dem Get Permission for a Single Resource API-Aufruf sehen Sie, welche Rollen die Berechtigungen für die Ressource /oauth2 haben.

Anhand der Antwort können Sie mit den API-Aufrufen Add Permissions for Resource to a Role (Rolle Berechtigungen für Ressource hinzufügen) und Delete Permission for Resource (Berechtigung für Ressource löschen) die erforderlichen Anpassungen an den /oauth2-Ressourcenberechtigungen vornehmen.

Verwenden Sie den folgenden cURL-Befehl, um der Rolle opsadmin die Berechtigungen get und put für die Ressource /oauth2 zuzuweisen. Ersetzen Sie die Werte in {geschweiften Klammern} durch Ihre organisationsspezifischen Werte:

> curl -X POST -H 'Content-type:application/xml' \
  http://<ms-ip>:8080/v1/organizations/{org}/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u {USEREMAIL}:{PWD}

Verwenden Sie den folgenden cURL-Befehl, um die get- und put-Berechtigungen für die Ressource /oauth2 für Rollen zu widerrufen, die nicht orgadmin oder opsadmin sind. Ersetzen Sie die Werte in {curly braces} durch Ihre organisationsspezifischen Werte:

> curl -X DELETE -H 'Content-type:application/xml' \
  http://<msip>:8080/v1/organizations/{org-name}/userroles/{roles}/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u {USEREMAIL}:{PWD}

Schritt 3: Das Attribut „oauth_max_search_limit“ festlegen

Achten Sie darauf, dass das Attribut conf_keymanagement_oauth_max_search_limit in der Datei /opt/apigee/customer/application/management-server.properties auf „100“ festgelegt ist:

conf_keymanagement_oauth_max_search_limit = 100

Wenn diese Datei nicht vorhanden ist, erstellen Sie sie.

Mit dieser Property wird die Seitengröße festgelegt, die beim Abrufen von Tokens verwendet wird. Apigee empfiehlt einen Wert von 100, aber Sie können ihn nach Belieben festlegen.

Bei einer Neuinstallation sollte die Property bereits auf 100 festgelegt sein. Wenn Sie den Wert dieser Eigenschaft ändern müssen, starten Sie den Verwaltungsserver und den Nachrichtenprozessor mit den folgenden Befehlen neu:

> /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Schritt 4: OAuth 2.0-Richtlinie für die Tokengenerierung so konfigurieren, dass die Endnutzer-ID enthalten ist

Konfigurieren Sie die OAuth 2.0-Richtlinie, die zum Generieren von Zugriffstokens verwendet wird, so, dass die Endnutzer-ID in das Token aufgenommen wird. Wenn Sie Endnutzer-IDs in das Zugriffstoken aufnehmen, können Sie Tokens nach ID abrufen und widerrufen.

Wenn Sie die Richtlinie so konfigurieren möchten, dass eine Endnutzer-ID in ein Zugriffstoken aufgenommen wird, muss die Anfrage, mit der das Zugriffstoken erstellt wird, die Endnutzer-ID enthalten. Außerdem müssen Sie die Eingabevariable angeben, die die Endnutzer-ID enthält.

Die folgende OAuth 2.0-Richtlinie mit dem Namen „GenerateAccessTokenClient“ generiert ein OAuth 2.0-Zugriffstoken. Beachten Sie das fett formatierte Tag <AppEndUser>, das die Variable mit der Endnutzer-ID angibt:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
    <DisplayName>OAuth 2.0.0 1</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <SupportedGrantTypes>
         <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
    <GrantType>request.queryparam.grant_type</GrantType> 
    <AppEndUser>request.header.appuserID</AppEndUser> 
    <ExpiresIn>960000</ExpiresIn>
</OAuthV2>

Sie können dann den folgenden cURL-Befehl verwenden, um das OAuth 2.0-Zugriffstoken zu generieren und die Nutzer-ID als appuserID-Header zu übergeben:

> curl -H "appuserID:6ZG094fgnjNf02EK" \
https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials \
  -X POST \
  -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'

In diesem Beispiel wird die appuserID als Anfrageheader übergeben. Sie können die Informationen als Teil einer Anfrage auf viele Arten übergeben. Alternativ haben Sie folgende Möglichkeiten:

Eine Formularparametervariable verwenden: request.formparam.appuserID
Eine Ablaufvariable mit der Endnutzer-ID verwenden