Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Activer l'accès aux jetons OAuth 2.0 par ID utilisateur et ID d'application

Edge for Private Cloud v. 4.16.09

Ce document explique comment activer la récupération et la révocation des jetons d'accès OAuth 2.0 par ID d'utilisateur final, ID d'application ou les deux.

Les ID d'application sont automatiquement ajoutés à un jeton d'accès OAuth. Par conséquent, après avoir suivi la procédure ci-dessous pour activer l'accès aux jetons pour une organisation, vous pouvez accéder aux jetons par ID d'application.

Pour récupérer et révoquer les jetons d'accès OAuth 2.0 par ID d'utilisateur final, un ID d'utilisateur final doit être présent dans le jeton d'accès. La procédure ci-dessous explique comment ajouter un ID d'utilisateur final à un jeton existant ou à de nouveaux jetons.

Par défaut, lorsqu'Edge génère un jeton d'accès OAuth 2.0, celui-ci est au format suivant :

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

Veuillez noter les points suivants :

Le champ application_name contient l'UUID de l'application associée au jeton. Si vous activez la récupération et la révocation des jetons d'accès OAuth 2.0 par ID d'application, il s'agit de l'ID d'application que vous utilisez.
Le champ access_token contient la valeur du jeton d'accès OAuth 2.0.

Pour activer la récupération et la révocation des jetons d'accès OAuth 2.0 par ID d'utilisateur final, configurez la règle OAuth 2.0 pour inclure l'ID utilisateur dans le jeton, comme décrit dans la procédure ci-dessous.

L'ID utilisateur final est la chaîne qu'Edge utilise comme ID de développeur, et non l'adresse e-mail du développeur. Vous pouvez déterminer l'ID du développeur à partir de son adresse e-mail à l'aide de l'appel d'API "Get Developer".

Une fois que vous avez configuré Edge pour inclure l'ID utilisateur final dans le jeton, il est inclus dans le champ "app_enduser", comme indiqué ci-dessous :

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

API permettant de récupérer et de révoquer des jetons d'accès OAuth 2.0 par ID utilisateur et ID d'application

Utilisez les API suivantes pour accéder aux jetons OAuth par ID utilisateur, ID d'application ou les deux :

Procédure d'activation de l'accès par jeton

Suivez la procédure ci-dessous pour activer la récupération et la révocation des jetons d'accès OAuth 2.0 par ID d'utilisateur final et ID d'application.

Étape 1 : Activez la compatibilité avec l'accès par jeton pour une organisation

Vous devez activer l'accès par jeton pour chaque organisation séparément. Appelez l'API PUT ci-dessous pour chaque organisation sur laquelle vous souhaitez activer la récupération et la révocation des jetons d'accès OAuth 2.0 par ID d'utilisateur final ou ID d'application.

L'utilisateur qui effectue l'appel suivant doit disposer du rôle orgadmin ou opsadmin pour l'organisation. Remplacez les valeurs entre {accolades} par les valeurs spécifiques à votre organisation :

> 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}

Étape 2 : Définissez les autorisations pour le rôle opsadmin dans l'organisation

Seuls les rôles orgadmin et opsadmin d'une organisation doivent être autorisés à récupérer (HTTP GET) et à révoquer (HTTP PUT) des jetons OAuth 2.0 en fonction de l'ID utilisateur ou de l'ID d'application. Pour contrôler l'accès, définissez les autorisations "get" et "put" sur la ressource /oauth2 d'une organisation. Cette ressource possède une URL au format suivant :

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

Le rôle orgadmin devrait déjà disposer des autorisations nécessaires. Pour le rôle opsadmin de la ressource /oauth2, les autorisations doivent se présenter comme suit :

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

Vous pouvez utiliser l'appel d'API Obtenir l'autorisation pour une seule ressource pour voir quels rôles disposent d'autorisations pour la ressource /oauth2.

En fonction de la réponse, vous pouvez utiliser les appels d'API Ajouter des autorisations pour une ressource à un rôle et Supprimer l'autorisation pour une ressource pour apporter les ajustements nécessaires aux autorisations de la ressource /oauth2.

Utilisez la commande cURL suivante pour accorder au rôle opsadmin les autorisations get et put pour la ressource /oauth2. Remplacez les valeurs entre {accolades} par les valeurs spécifiques à votre organisation :

> 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}

Utilisez la commande cURL suivante pour révoquer les autorisations get et put pour la ressource /oauth2 des rôles autres que orgadmin et opsadmin. Remplacez les valeurs entre {accolades} par les valeurs spécifiques à votre organisation :

> 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}

Étape 3 : Définissez la propriété oauth_max_search_limit

Assurez-vous que la propriété conf_keymanagement_oauth_max_search_limit du fichier /<inst_dir>/apigee/customer/application/management-server.properties est définie sur 100 :

conf_keymanagement_oauth_max_search_limit = 100

Si ce fichier n'existe pas, créez-le.

Cette propriété définit la taille de la page utilisée lors de la récupération des jetons. Apigee recommande une valeur de 100, mais vous pouvez la définir comme bon vous semble.

Sur une nouvelle installation, la propriété doit déjà être définie sur 100. Si vous devez modifier la valeur de cette propriété, redémarrez le serveur de gestion et le processeur de messages à l'aide des commandes suivantes :

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

Étape 4 : Configurez la règle OAuth 2.0 qui génère des jetons pour inclure l'ID utilisateur final

Configurez la règle OAuth 2.0 utilisée pour générer des jetons d'accès afin d'inclure l'ID utilisateur final dans le jeton. En incluant les ID d'utilisateur final dans le jeton d'accès, vous pouvez récupérer et révoquer les jetons par ID.

Pour configurer la règle de sorte qu'elle inclue un ID d'utilisateur final dans un jeton d'accès, la requête qui crée le jeton d'accès doit inclure l'ID d'utilisateur final, et vous devez spécifier la variable d'entrée qui contient l'ID d'utilisateur final.

La règle OAuth 2.0 ci-dessous, nommée GenerateAccessTokenClient, génère un jeton d'accès OAuth 2.0. Notez l'ajout de la balise <AppEndUser> en gras qui spécifie la variable contenant l'ID de l'utilisateur final :

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

Vous pouvez ensuite utiliser la commande cURL suivante pour générer le jeton d'accès OAuth 2.0, en transmettant l'ID utilisateur en tant qu'en-tête appuserID :

> 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'

Dans cet exemple, l'appuserID est transmis en tant qu'en-tête de requête. Vous pouvez transmettre des informations dans une requête de différentes manières. Par exemple, vous pouvez également :

Utiliser une variable de paramètre de formulaire : request.formparam.appuserID.
Utiliser une variable de flux fournissant l'ID d'utilisateur final