Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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

Edge for Private Cloud v. 4.16.09

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

App-IDs werden automatisch einem OAuth-Zugriffstoken hinzugefügt. Nachdem Sie das folgende Verfahren zum Aktivieren des Tokenzugriffs für eine Organisation verwendet haben, können Sie daher über die App-ID auf Tokens zugreifen.

Wenn Sie OAuth 2.0-Zugriffstokens nach Endnutzer-ID abrufen und widerrufen möchten, muss im Zugriffstoken eine Endnutzer-ID vorhanden sein. Im Folgenden wird beschrieben, wie Sie eine Endnutzer-ID zu einem vorhandenen Token oder zu neuen Tokens hinzufügen.

Wenn Edge ein OAuth 2.0-Zugriffstoken generiert, hat das Token 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, ist dies die App-ID, die Sie verwenden.
Das Feld access_token enthält den Wert des OAuth 2.0-Zugriffstokens.

Wenn Sie das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Endnutzer-ID aktivieren möchten, konfigurieren Sie die OAuth 2.0-Richtlinie so, dass die Nutzer-ID im Token enthalten ist. Gehen Sie dazu wie unten beschrieben vor.

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

Nachdem Sie Edge so konfiguriert haben, dass die Endnutzer-ID im Token enthalten ist, wird sie wie unten gezeigt im Feld „app_enduser“ eingefügt:

{
  "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

Verwenden Sie die folgenden APIs, um nach Nutzer-ID, App-ID oder beidem auf OAuth-Tokens zuzugreifen:

Verfahren zum Aktivieren des Tokenzugriffs

Gehen Sie so vor, um das Abrufen und Widerrufen von OAuth 2.0-Zugriffstokens nach Endnutzer-ID und App-ID zu aktivieren.

Schritt 1: Unterstützung für 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 Anwendungs-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 {geschweiften Klammern} 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. Wenn Sie den Zugriff steuern möchten, legen Sie für die Ressource „/oauth2“ einer Organisation die Berechtigungen „get“ und „put“ 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 API-Aufruf Berechtigung für eine einzelne Ressource abrufen können Sie sehen, welche Rollen Berechtigungen für die Ressource /oauth2 haben.

Anhand der Antwort können Sie die API-Aufrufe Berechtigungen für Ressource zu einer Rolle hinzufügen und Berechtigung für Ressource löschen verwenden, um die erforderlichen Anpassungen an den Berechtigungen für die Ressource „/oauth2“ vorzunehmen.

Verwenden Sie den folgenden cURL-Befehl, um der Rolle opsadmin die Berechtigungen get und put für die Ressource /oauth2 zu erteilen. 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 Berechtigungen get und put für die Ressource /oauth2 für andere Rollen als orgadmin und opsadmin zu widerrufen. Ersetzen Sie die Werte in {geschweiften Klammern} 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: Attribut „oauth_max_search_limit“ festlegen

Achten Sie darauf, dass das Attribut conf_keymanagement_oauth_max_search_limit in der Datei /<inst_dir>/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 diesem Attribut wird die Seitengröße festgelegt, die beim Abrufen von Tokens verwendet wird. Apigee empfiehlt den Wert 100, Sie können ihn aber nach Bedarf festlegen.

Bei einer Neuinstallation sollte die Property bereits auf 100 festgelegt sein. Wenn Sie den Wert dieses Attributs ändern müssen, starten Sie den Management Server und den Message Processor mit den folgenden Befehlen neu:

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

Schritt 4: OAuth 2.0-Richtlinie konfigurieren, die Tokens generiert, um die Endnutzer-ID einzuschließen

Konfigurieren Sie die OAuth 2.0-Richtlinie, die zum Generieren von Zugriffstokens verwendet wird, so, dass die Endnutzer-ID im Token enthalten ist. 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, die das Zugriffstoken erstellt, die Endnutzer-ID enthalten. Außerdem müssen Sie die Eingabevariable angeben, die die Endnutzer-ID enthält.

Die unten aufgeführte 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>

Anschließend können Sie mit dem folgenden cURL-Befehl das OAuth 2.0-Zugriffstoken generieren und die Nutzer-ID als appuserID-Header ü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 Informationen auf verschiedene Arten als Teil einer Anfrage übergeben. Alternativ haben Sie folgende Möglichkeiten:

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