Le besoin de base reste identique: obtenir un refresh token, puis generer un access token exploitable dans les appels API. En revanche, le mecanisme historique de creation du refresh token en vRA 8.x n'est plus la reference cible en VCF Automation 9.1.
Dans les scripts historiques vRA 8.x, le schema etait generalement le suivant:
Exemple de creation de refresh token en vRA 8.x:
POST {{vra}}/csp/gateway/am/api/login?access_token
Content-Type: application/json
{
"username": "{{username}}",
"password": "{{password}}"
}
Puis generation du bearer token:
POST {{vra}}/csp/gateway/am/api/auth/api-tokens/authorize?refresh_token={{refresh_token}}
Accept: application/json
Ce mecanisme explique la structure de nombreux scripts existants.
En cible VCF Automation 9.1, la creation initiale du refresh token ne repose plus sur le meme usage login/password des anciens scripts.
Il existe maintenant deux methodes possibles:
Les deux methodes permettent ensuite de generer un access token via OAuth.
Cette methode est adaptee pour les tests, les validations rapides et les usages personnels.
Dans l'organisation cible:
Le token affiche est a conserver dans le gestionnaire de secrets. Dans ce flux, il est utilise comme refresh token.
POST {{vra}}/tm/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=refresh_token&refresh_token={{api_token_utilisateur}}
Selon l'environnement, l'endpoint fonctionnel peut etre /oauth/tenant/{{org}}/token ou /tm/oauth/tenant/{{org}}/token. La pratique recommandee consiste a standardiser un seul endpoint valide dans les scripts.
Pour une automatisation durable (jobs planifies, pipelines CI/CD, integrations), cette methode constitue la cible prioritaire.
Dans l'organisation VCF Automation cible:
Etat attendu apres creation: Created.
Dans la ligne du Service Account:
Point critique: utiliser Client ID pour OAuth, et non Software ID.
@vra = https://vcfa.example.com
@org = vcfa
@client_id = remplacer_par_client_id
###
# @name DemandeAutorisation
POST {{vra}}/oauth/tenant/{{org}}/device_authorization
Content-Type: application/x-www-form-urlencoded
Accept: application/json
client_id={{client_id}}
La reponse contient notamment device_code et user_code.
Toujours dans:
Puis:
Etat attendu: Granted.
###
# @name CreationTokensServiceAccount
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id={{client_id}}&device_code={{device_code}}
Points de controle:
Une fois le refresh token disponible, les scripts doivent utiliser:
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=refresh_token&refresh_token={{refresh_token}}
Le champ access_token est le bearer token a envoyer dans les appels API.
Si la rotation est active, chaque renouvellement du Bearer Token renvoi un nouveau refresh token.
Remplacer les appels historiques:
/csp/gateway/am/api/login?access_token/csp/gateway/am/api/auth/api-tokens/authorizePar les endpoints OAuth 9.1:
/oauth/tenant/{org}/device_authorization/oauth/tenant/{org}/tokenPour OAuth:
Content-Type: application/x-www-form-urlencodedA introduire ou normaliser dans les scripts:
@vra = https://vcfa.example.com
@org = vcfa
@client_id = remplacer_par_client_id
@device_code = remplacer_par_device_code
@refresh_token = remplacer_par_refresh_token
###
# Etape 1 - Demande d'autorisation Service Account
POST {{vra}}/oauth/tenant/{{org}}/device_authorization
Content-Type: application/x-www-form-urlencoded
Accept: application/json
client_id={{client_id}}
###
# Etape manuelle IHM
# Infrastructure > Access Control > Service Accounts
# Review Access Requests > user_code > Lookup > Grant
###
# Etape 2 - Echange initial
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id={{client_id}}&device_code={{device_code}}
###
# Etape 3 - Renouvellement standard
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=refresh_token&refresh_token={{refresh_token}}
> {%
client.global.set("access_token", response.body.access_token);
client.global.set("refresh_token", response.body.refresh_token);
%}
###
# Etape 4 - Appel API metier
GET {{vra}}/iaas/api/projects
Authorization: Bearer {{access_token}}
Accept: application/json
La migration vRA 8.x vers VCF Automation 9.1 doit remplacer le flux historique de creation du refresh token par un flux OAuth cible, en choisissant explicitement l'une des deux methodes:
La stabilite de la cible repose sur trois exigences:
application/x-www-form-urlencoded respecteNavigation:
Navigation:
Navigation:
${project}, ${deployment}, ${resource}, ${sequence}Navigation:
Navigation:
Navigation:
Navigation:
Des retours d'expérience, des guides pratiques et des actualités sur l'écosystème VCF seront publiés régulièrement.
]]>