Fédérer l'identité VCF : Okta, Entra ID, et le chemin générique

Un audit exige la révocation complète d’un départ en moins de 24 heures, sur tout le parc. Huit consoles, huit comptes locaux, un tableur de mots de passe partagé par l’astreinte : la réponse honnête est non. Fédérer l’authentification sur l’annuaire d’entreprise est le seul chemin qui change cette réponse — encore faut-il savoir quel fournisseur Broadcom documente réellement, avec quel protocole, et ce qui casse à la toute première connexion.

Cet article ne montre pas comment créer une application dans Okta ou dans Azure. Il trace la frontière : ce que VCF exige côté VCF Identity Broker, ce que votre fournisseur doit produire en face, et les endroits précis où les deux ne se rencontrent pas. Tout ce qui suit vient de pages Broadcom et d’éditeurs tiers chargées le 15 août 2026. Aucun lab n’a été exécuté, aucune capture n’a été prise, aucune durée n’a été relevée : c’est un guide de cadrage, pas un compte rendu d’exécution.

TL;DR

• La décision : choisir le protocole avant le fournisseur. SAML 2.0 et OIDC n’exigent pas les mêmes champs et surtout n’attendent pas les mêmes noms de claims. Se tromper de jeu ne produit aucune erreur explicite.
• L’arbitrage qui coûte : fédérer les consoles ne ferme pas tout. Les jetons d’API de l’Identity Broker vivent 30 jours par défaut, et rien dans la documentation chargée n’établit qu’ils meurent avec la désactivation du compte amont. La révocation en 24 h reste une procédure, pas une conséquence.
• L’action de lundi matin : avant d’ouvrir l’assistant, créer l’Emergency Access Client, inscrire le compte local administrator@vsphere.local du domaine de gestion dans la procédure d’astreinte, et sauvegarder le vCenter du domaine de gestion et l’appliance VCF Identity Broker.

Ce que Broadcom documente, fournisseur par fournisseur

La compatibilité n’est pas une case à cocher : c’est un couple fournisseur × protocole. La matrice publiée sépare d’ailleurs deux axes que la plupart des comparatifs fusionnent — et les fusionner produit un tableau faux.

Axe	Valeurs publiées	Question à laquelle il répond
Protocole d’authentification	SAML 2.0, OIDC, LDAP	comment l’utilisateur prouve son identité
Approvisionnement	SCIM 2.0, JIT, AD/LDAP	d’où viennent les utilisateurs et les groupes

La page Identity Providers and Protocols Supported for VCF Single Sign-On définit SAML 2.0 par l’émission d’assertions XML signées, et OIDC comme un protocole bâti sur OAuth 2.0 dont le jeton d’identité est au format JSON. Elle range les fournisseurs en deux familles : modern identity providers et directory-based identity providers.

Fournisseur	Nommé par Broadcom	SAML 2.0	OIDC	Ce qui l’établit
Okta	oui	annoncé par l’index et la matrice	page de procédure chargée	index Okta 9.1 + matrice
Microsoft Entra ID	oui	page de procédure chargée	page de procédure chargée	deux pages dédiées
Ping Identity	oui	page de procédure chargée	page de procédure chargée	deux pages dédiées
Microsoft ADFS	oui	index parent chargé	page de procédure chargée	index + page OIDC
Generic SAML 2.0	oui	page de procédure chargée	—	une page dédiée
Active Directory	oui	—	—	via AD/LDAP
OpenLDAP	oui	—	—	via LDAP
Keycloak	non, nulle part	—	—	aucune page

Deux conséquences. Ping Identity et Microsoft ADFS ne sont pas des lignes de second rang : chacun de leurs deux chemins protocolaires dispose d’une page. Et la formule publiée « Any SAML 2.0 Identity Providers » porte sur SAML 2.0, sur lui seul ; elle n’ouvre pas un support OIDC générique. Un tel support annoncé en 9.1 circule en extrait de moteur de recherche, mais n’a été retrouvé sur aucune page de documentation chargée : il reste à valider sur votre plateforme et ne fonde rien ici.

Une curiosité vérifiable, qui change la façon de chercher : l’URL dont le dernier segment annonce ...-with-okta-using-saml.html sert une page intitulée Configure Okta as an Identity Provider using OIDC, avec les champs et les claims OIDC. Le renommage des pages a été plus rapide que celui des chemins. Conséquence à assumer : l’URL de la page de procédure Okta / SAML n’a pas été identifiée, et aucun détail de cette procédure n’est donc citable — seule l’existence du chemin l’est, par l’index et la matrice.

Le chemin générique — et donc Keycloak

Keycloak n’est nommé sur aucune page Broadcom chargée : ni dans la matrice, ni dans les sept sous-sections de l’étape de configuration d’un fournisseur. Le seul chemin qui l’englobe est Configure an Identity Provider using Generic SAML 2.0, et il l’englobe par conformité au protocole, pas par nom.

La formulation exacte compte. Keycloak est un fournisseur d’identité conforme à SAML 2.0 ; à ce titre il tombe dans la catégorie publiée « Any SAML 2.0 Identity Providers », que VCF documente par une procédure générique. Broadcom ne le nomme nulle part, ne publie pas de procédure pour lui et ne s’engage pas sur son comportement. Conformité au protocole et support produit ne sont pas la même chose.

Ce que la page générique exige suffit à cadrer le travail sans décrire un seul écran Keycloak :

1. créer une application SAML 2.0 dans la console d’administration du fournisseur ;
2. fournir les métadonnées, en URL ou en XML ;
3. choisir le format et la valeur du Name ID ;
4. choisir le SAML Context ;
5. ajouter un attribut de groupe — « In the group attributes section of the workflow you can add a group attribute to be called for in the SAML request » ;
6. choisir une méthode d’approvisionnement : SCIM, JIT ou AD/LDAP.

Côté Keycloak, ces exigences se traduisent en objets que la documentation de l’éditeur nomme : le Server Administration Guide 26.7.1 décrit « Creating a SAML client », « Managing OpenID Connect clients » et « OIDC token and SAML assertion mappings » — « you can tailor what claims and assertions are stored in the OIDC token or SAML assertion ». C’est par là qu’un claim groups attendu par VCF serait produit. Aucune page chargée, ni chez Broadcom ni chez Keycloak, ne décrit cet appariement. L’article s’arrête là, volontairement.

Deux protocoles, deux jeux de claims

Voici le piège numéro un, publié noir sur blanc mais jamais au même endroit. Les noms diffèrent selon le protocole, la casse compte, et rien dans l’interface ne prévient qu’on a recopié la mauvaise liste.

Rôle du claim	Jeu SAML	Jeu OIDC
identifiant de connexion	userName	preferred_username
adresse électronique	email	email
domaine	domain	domain
prénom	firstName	given_name
nom	lastName	family_name
appartenance de groupe	groups	groups

Le jeu SAML est relevé sur les pages Entra ID / SAML et Ping Identity / SAML : « Ensure that you add the following default claims when you configure your external identity provider. Note that these claims are case-sensitive ». Le jeu OIDC l’est sur les pages Entra ID / OIDC, Ping Identity / OIDC et Okta / OIDC, avec le même avertissement. La page Ping Identity / OIDC ouvre une soupape — « if the default claims cannot be added, use alternative claim names and map them to appropriate attributes » — mais cette correspondance n’est décrite champ par champ nulle part.

Trois noms seulement sont communs : email, domain, groups. Aucune page ne présente les deux listes côte à côte ; le tableau ci-dessus assemble cinq pages. Conséquence directe : qui migre une intégration SAML vers OIDC, ou l’inverse, refait son mapping de claims — il ne le recopie pas.

Les champs de l’écran Identity Provider Configuration divergent de la même façon. Les valeurs sensibles restent des emplacements nommés, jamais des exemples : un faux secret finit copié-collé, un emplacement nommé, non.

champs_oidc:            # Entra ID, Ping Identity, ADFS, Okta
  idp_display_name: REPLACE_WITH_IDP_DISPLAY_NAME
  client_identifier: REPLACE_WITH_CLIENT_ID
  shared_secret: REPLACE_WITH_SHARED_SECRET
  openid_address: REPLACE_WITH_OPENID_ADDRESS
  redirect_uri: REPLACE_WITH_REDIRECT_URI
  ssl_certificate: REPLACE_WITH_CA        # requis seulement si certificat auto-signé

champs_saml:            # Entra ID, Ping Identity, Generic SAML 2.0
  idp_display_name: REPLACE_WITH_IDP_DISPLAY_NAME
  metadata_mode: url | xml                # « Metadata URL » ou « Metadata XML »
  metadata_value: REPLACE_WITH_IDP_METADATA
  name_id_format: REPLACE_WITH_NAMEID_FORMAT
  name_id_value: REPLACE_WITH_NAMEID_VALUE
  saml_context: PasswordProtectedTransport | Password | Unspecified

Trois précisions publiées méritent une ligne dans votre document d’architecture. Le Name ID : « The Name ID format is the value in the SAML response to identify the authenticated user ». Les métadonnées : pour un fournisseur non joignable publiquement, la page générique prévoit la fourniture du XML au lieu de l’URL — le mode d’un fournisseur auto-hébergé. Le certificat SSL côté OIDC : « required only if a self-signed certificate is used ».

L’ordre réel des opérations

Le parcours publié compte sept étapes : sélection de l’instance, mode de déploiement, configuration du fournisseur d’identité, SSO pour NSX et vCenter, SSO pour VCF Operations et VCF Automation, SSO optionnel pour les autres composants, attribution des rôles. Cet article vit dans la troisième, et cette troisième étape fait sortir l’opérateur de VCF Operations au milieu du parcours.

L’aller-retour est publié tel quel : la page Ping Identity / SAML écrit, à l’intérieur du parcours VCF, « log in to your Ping Identity admin console and follow the steps in Ping Identity to create a SAML 2.0 application ». La page générique porte la même mécanique. D’où la seule règle de séquencement qui compte : on n’ouvre pas l’assistant VCF avant d’avoir le droit de créer une application dans le fournisseur d’identité. Sur un annuaire géré par une autre équipe, l’assistant reste ouvert le temps d’un ticket.

prealables:
  elm_desactive_sur_toutes_les_instances_vcenter: requis  # et ne pas le réactiver ensuite
  vcenter_du_domaine_de_gestion: "9.0 ou ultérieure, licence VMware Cloud Foundation"
  portee_all_objects_dans_vcf_operations: requise pour l'opérateur
  configuration: "exclusivement via VCF Operations, jamais depuis les composants"
  composants_cibles: "licenciés, 9.0 ou ultérieure"
  proxy_http_si_appliance_sans_acces_sortant: requis
  sauvegarde_prealable: "vCenter du domaine de gestion + appliance VCF Identity Broker"
  droit_de_creer_une_application_dans_l_idp: requis

La consigne de sauvegarde est publiée mot pour mot sur les pages de procédure Okta et Ping Identity — « It is highly advisable to create a backup of both the management domain vCenter and the VCF Identity Broker appliance ». Elle vit dans une page de configuration de fournisseur, pas dans une page de sauvegarde : exactement là où personne ne la cherche.

Deux comportements se tranchent en avant-projet. La configuration de fournisseur existante de vCenter est écrasée, tandis que les autres composants reçoivent le SSO comme source d’authentification supplémentaire et réclament un re-provisionnement des utilisateurs et des groupes. Ensuite, les configurations Active Directory, OpenLDAP ou ADFS existantes sont partiellement importées, mais l’import des fournisseurs modernes — Okta, Entra ID, Ping — est restreint au mode embedded. Une autre page annonce plus largement la réutilisation d’une configuration existante : les deux formulations sont publiées, leur composition exacte ne l’est pas. Si votre design retient le mode appliance, traitez ce point comme un critère d’arbitrage et vérifiez-le sur votre plateforme avant de promettre une reprise de l’existant.

Les quatre endroits où ça casse

Dans l’ordre où le problème se produit, pas dans l’ordre où on y pense.

1. Le claim groups doit exister et être peuplé. Il figure dans les deux jeux obligatoires, et rien dans les pages chargées ne décrit ce que fait VCF quand il est absent ou vide.

2. Le fournisseur peut décider de ne pas l’émettre, silencieusement. Ce fait vient de la documentation des éditeurs, pas de Broadcom. Microsoft Learn publie, pour Microsoft Entra ID : « The number of groups emitted in a token is limited to 150 for SAML assertions and 200 for JWT, including nested groups. […] Exceeding this limit will cause Microsoft Entra ID completely omit sending group claims in the token » — un lien Microsoft Graph est émis à la place. Contournements publiés : restreindre l’émission aux groupes assignés à l’application, ou poser un filtre de groupes, ce dernier valable « only if a user belongs to 1,000 or fewer groups ». Côté Okta, la documentation de l’éditeur situe le réglage dans l’onglet Sign On de l’application OpenID Connect, section OpenID Connect ID Token, champ Group claim type avec le choix Filter ou Expression. Une limite de 100 groupes pour le claim Okta circule largement en extrait de recherche : elle n’a été retrouvée sur aucune page Okta chargée, elle n’est donc pas reprise ici.

Le mode de défaillance qui en découle est contre-intuitif : un utilisateur membre de trop de groupes ne se connecte pas « avec moins de droits », il se connecte sans aucune appartenance, sur un jeton dépourvu du claim. Un compte de service propre, membre d’un seul groupe, ne le révèle jamais.

3. Le format de connexion n’est pas celui qu’on croit. La KB Broadcom 393150 publie : « The user needs to log in using userName@domain in VCF SSO 9.0 for the login to be successful. » Le cas décrit est un suffixe d’UPN différent du nom de domaine, qui impose une forme composée — REPLACE_WITH_UPN@REPLACE_WITH_UPN_SUFFIX@REPLACE_WITH_SSO_DOMAIN. Produits déclarés affectés : VCF Operations 9.0 et vCenter 9.0.

4. Fédérer ne donne aucun droit. Après la connexion des composants, il faut encore se connecter localement à chaque composant en administrateur pour attribuer les rôles de service. Les six rôles VCF intégrés sont mappés sur les rôles des composants, et la documentation précise qu’ils ne visent pas à remplacer leurs modèles d’autorisation.

Groupe reçu dans groups	Rôle VCF visé	Rôle composant attendu
grp-vcf-admins	VCF Administrator	vCenter Admin, NSX enterprise_admin
grp-vcf-viewers	VCF Viewer	vCenter ReadOnly, NSX auditor
grp-nsx-secops	REPLACE_WITH_VCF_ROLE	rôle de sécurité à attribuer dans NSX
grp-app-webshop-owners	REPLACE_WITH_VCF_ROLE	délégation traitée dans l’article suivant

Cette correspondance est construite, à confirmer composant par composant. La troisième ligne est le cas instructif : un besoin « écriture de politiques de sécurité NSX » se satisfait dans le modèle de rôles NSX, pas dans le modèle VCF. Pour la première connexion, un ordre de diagnostic tient en un tableau — reconstitué à partir des prérequis et des limites publiés, car aucun chemin de log n’est publié pour l’authentification fédérée.

Symptôme	Première hypothèse	Vérification
authentification refusée alors que le fournisseur annonce un succès	format de connexion	essayer la forme upn@domain avant tout autre diagnostic
connexion acceptée, aucun groupe visible	claim groups non émis	compter les appartenances ; restreindre aux groupes assignés à l’application
certains groupes seulement remontent	filtre de groupes côté fournisseur	relire le filtre, vérifier le plafond de filtrage
claims présents mais ignorés	casse ou nom de claim	comparer au jeu du protocole retenu, pas à l’autre
groupe présent, aucun droit dans un composant	rôle de service non attribué localement	se connecter au composant en admin et attribuer le rôle
l’assistant échoue avant la saisie du fournisseur	ELM encore actif, version, licence	reprendre les prérequis avant de relancer
l’appliance ne joint pas le fournisseur	absence de proxy sortant	exigence publiée ; la KB citée par la page n’a pas été résolue
session toujours ouverte ailleurs après déconnexion	déconnexion par composant et par navigateur	comportement publié, pas un défaut

MFA, jetons et retour en arrière

La direction du produit est explicite côté vSphere 9.0 : « In vSphere 9.0 and later, external identity provider federation is the preferred authentication method for vCenter », et « Native vCenter features for multi-factor authentication is deprecated in favor of leveraging the external identity providers capabilities or multi-factor authentication ». Le MFA se traite chez le fournisseur. Côté Microsoft, l’accès conditionnel Entra s’applique « after first-factor authentication is completed », se cible par application et propose la décision « Require multifactor authentication », sous licence Entra ID P1 — documentation Microsoft, pas Broadcom.

Reste ce que la documentation Broadcom ne dit pas. Le seul levier exposé dans l’assistant SAML est le champ SAML Context, avec trois valeurs publiées : PasswordProtectedTransport, Password, Unspecified — aucune ne correspond à une authentification multifacteur. Depuis les pages chargées, on ignore donc si l’Identity Broker peut exiger un contexte MFA plutôt que le subir, et aucune page ne décrit ce que VCF fait d’un refus d’accès conditionnel ou d’un changement de posture en cours de session. La formulation défendable : les politiques du fournisseur s’appliquent à la porte ; ce qui vit derrière la porte est gouverné par les jetons de VCF.

Et c’est là que le fil rouge se paie. L’Identity Broker émet ses propres jetons : API token 30 jours par défaut, access token 30 minutes par défaut, plafonnés par les réglages API Token Expiry et Access Token Expiry sous Fleet Settings puis IAM Setting. Désactiver le compte chez le fournisseur ferme la porte d’entrée interactive ; rien dans les pages chargées n’établit qu’un jeton d’API déjà émis cesse alors de fonctionner. Tant que ce point n’est pas relevé sur votre instance, la procédure de départ doit inclure une revue explicite des clients et jetons d’API. Second angle mort, publié celui-là : « When you log out, the session ends exclusively for that particular VCF component within the designated browser ». Un SSO d’entrée n’est pas une déconnexion globale.

Le retour en arrière existe, il est documenté, et il est brutal. Depuis VCF Operations, Fleet Management puis Identity & Access, on sélectionne l’instance, on ouvre l’onglet Identity Source et on lance Reset SSO. Ce qui est perdu est publié : « The provisioned users and groups are removed. Ensure that the users and groups are assigned the required service roles in each component after you complete configuring the identity provider. » Ce qui est conservé aussi : le mode de déploiement et la configuration des composants clients. Le changement de mode de déploiement passe par la même réinitialisation. Aucune bascule d’un fournisseur vers un autre sans interruption n’est publiée : ne promettez ni migration à chaud, ni impossibilité de revenir.

Pièges & points de vigilance

Quatre portes de secours sont documentées, et elles s’ouvrent avant la première connexion fédérée. Les comptes locaux @vsphere.local restent le seul moyen d’entrer dans l’interface SDDC Manager — « administrators are no longer able to log in to the SDDC Manager UI client with Single Sign-On users », les API acceptant en revanche les utilisateurs SSO. vCenter « continues to have local accounts, for administrative access and error recovery ». La section Managing API Clients and Tokens documente la création d’un Emergency Access Client. Et la sauvegarde préalable est réclamée par les pages de procédure elles-mêmes.

Deux réflexes complètent la liste. Ne déduisez pas d’un protocole supporté une procédure disponible : le chemin Okta / SAML existe d’après l’index et la matrice, mais sa page n’a pas pu être identifiée. Et ne confondez jamais authentification et approvisionnement : SCIM 2.0, JIT et AD/LDAP répondent à « d’où viennent les utilisateurs et les groupes », pas à « comment ils prouvent leur identité ».

Conclusion

Si vous avez lu VCF Identity Broker : où s’arrête vraiment le SSO de VCF 9.1, vous saviez quelles consoles sont couvertes ; vous savez maintenant avec quoi les alimenter, et à quel prix. Les prérequis de plateforme sont posés dans La nouvelle architecture VCF 9 expliquée aux architectes, prolongés côté durcissement par VCF 9.1 : sécurité et résilience.

Une dernière chose, inconfortable. Les groupes grp-vcf-admins, grp-vcf-viewers et grp-nsx-secops arrivent maintenant du fournisseur d’entreprise et portent des rôles dans vCenter, dans NSX et dans VCF Operations. On en conclut naturellement qu’on détient une identité utilisable partout, y compris pour désigner qui a le droit de parler à quoi sur le réseau. C’est faux : la fonction Identity Firewall crée des règles fondées sur un groupe utilisateur Active Directory, et aucune page chargée ne relie le claim groups d’un jeton émis par le VCF Identity Broker à un objet de règle de pare-feu. L’annuaire Active Directory de corp.example ne disparaît donc pas parce que les consoles sont fédérées ailleurs : il reste la source d’identité du plan réseau. vDefend Distributed Firewall : le zero trust au niveau du workload explique pourquoi, et ce que cela coûte.