Cette page a été traduite par l'API Cloud Translation.

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

Edge pour Private Cloud version 4.17.09

Ce document explique comment activer la récupération et la révocation des jetons d'accès OAuth 2.0 en l'ID utilisateur final et/ou l'ID de l'application.

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

Pour récupérer et révoquer des 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 décrit 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, le jeton a le 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, c'est 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 de l'utilisateur final est la chaîne utilisée par Edge comme ID de développeur, pas l'adresse e-mail du développeur adresse e-mail. Vous pouvez déterminer l'identifiant du développeur à partir de son adresse e-mail à l'aide de la commande Get de l'API Developer.

Après avoir configuré Edge pour inclure l'ID de l'utilisateur final dans le jeton, il est inclus en tant que 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 à récupérer et à révoquer 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 aux jetons

Procédez comme suit pour activer la récupération et la révocation des jetons d'accès OAuth 2.0 par l'ID de l'utilisateur final et l'ID de l'application.

Étape 1: Activer la prise en charge de 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 pour laquelle vous souhaitez activer la récupération et la révocation des jetons d'accès OAuth 2.0 par l'ID de l'utilisateur final ou l'ID de l'application.

L'utilisateur effectuant l'appel suivant doit disposer du rôle orgadmin ou opsadmin pour l'organisation. Remplacez les valeurs entre {curly braces} par les valeurs spécifiques à l'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éfinir les autorisations du rôle opsadmin dans l'organisation

Seuls les rôles orgadmin et opsadmin dans une organisation doit avoir l'autorisation de récupérer (HTTP GET) et de révoquer (HTTP PUT) les jetons OAuth 2.0 basés sur sur l'ID utilisateur ou l'ID de l'application. Pour contrôler les accès, définissez les autorisations "get" et "put" sur la ressource /oauth2 pour une organisation. Cette ressource possède une URL au format suivant:

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

Le rôle orgadmin doit déjà disposer des autorisations nécessaires. Pour le opsadmin pour la ressource /oauth2, les autorisations doivent ressembler à ceci ceci:

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

Vous pouvez utiliser la commande Get Autorisation pour un appel d'API à ressource unique afin de voir quels rôles disposent des autorisations pour ressource /oauth2.

En fonction de la réponse, vous pouvez utiliser le bouton Ajouter Autorisations associées aux ressources d'un rôle et Supprimez l'autorisation pour les appels d'API de ressource afin d'apporter les ajustements nécessaires à /oauth2. les autorisations liées aux ressources.

Utilisez la commande cURL suivante pour attribuer au rôle opsadmin les autorisations get et put pour la ressource /oauth2. Remplacez les valeurs dans {curly braces} par les valeurs spécifiques à l'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 de la ressource /oauth2 pour des rôles autres que orgadmin et opsadmin. Remplacez les valeurs entre {curly braces} par les valeurs spécifiques à l'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 Propriété oauth_max_search_limit

Assurez-vous que la valeur conf_keymanagement_oauth_max_search_limit dans /opt/apigee/customer/application/management-server.properties est défini 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 page utilisée lors de la récupération des jetons. Apigee recommande une valeur de 100, mais vous pouvez le définir comme vous le souhaitez.

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

> /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
> /opt/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 de l'utilisateur final

Configurez la stratégie 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'utilisateurs finaux dans le jeton d'accès, vous pouvez récupérer et révoquer des jetons en ID.

Pour configurer la règle afin d'inclure 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 de l'utilisateur final et vous devez spécifier la variable d'entrée qui contenant l'ID de l'utilisateur final.

La règle OAuth 2.0 ci-dessous, nommée GenerateAccessTokenClient, génère un accès OAuth 2.0 à partir d'un jeton d'accès. Notez l'ajout en gras de la balise <AppEndUser> indiquant 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. Il existe de nombreuses façons de transmettre des informations dans le cadre d'une requête. 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