L'intégration technique entre Cloudflare Access et un fournisseur d'identité d'entreprise prend dans la plupart des cas moins d'une heure : échange de métadonnées, quelques URL, tests d'authentification. Ce qui prend des semaines, c'est la suite : décider quels groupes ont accès à quelles applications, avec quelle durée de session, avec quelles exigences MFA et que faire avec les collaborateurs externes sur un autre IdP. La configuration du protocole est un détail de la documentation. L’architecture politique est une décision de conception.
SAML, OIDC et ce qui compte lors du choix
Cloudflare Access prend en charge à la fois SAML 2.0 et OIDC. Pour les grands fournisseurs d'entreprises — Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud — Cloudflare maintient des guides d'intégration avec un mappage précis des champs. Le choix entre SAML et OIDC est rarement une décision technique critique ; Les deux fonctionnent de manière équivalente pour le cas d’utilisation de l’authentification Access.
La différence pratique est que OIDC est plus simple à configurer pour les fournisseurs modernes et renvoie directement les attributs au format JWT. SAML nécessite le mappage d'attributs au format d'assertion XML, ce qui ajoute des frictions dans des configurations plus complexes, en particulier lorsque vous souhaitez transmettre des attributs personnalisés de l'IdP pour les utiliser dans des stratégies. Pour les nouvelles intégrations avec Okta ou Azure AD, OIDC est la voie de moindre résistance.
Plusieurs fournisseurs d'identité simultanément
Une fonctionnalité Access qui passe inaperçue dans les premiers projets : une même organisation peut avoir plusieurs fournisseurs configurés et affecter différents fournisseurs à différentes applications. Une application accepte l'authentification via Google Workspace pour les collaborateurs et via GitHub pour les collaborateurs externes. Un autre se limite exclusivement à l'entreprise Okta. Un troisième affiche le menu de choix permettant à l'utilisateur de sélectionner le fournisseur à utiliser.
Cela résout le scénario fréquent des entreprises ayant des employés dans différentes entreprises partenaires, chacune disposant de son propre Azure AD ou Google Workspace. Au lieu de créer des comptes invités sur tous les fournisseurs, Access accepte plusieurs fournisseurs avec des politiques différentes par fournisseur. La limite pratique n'est pas technique, elle est gestion : chaque fournisseur supplémentaire est un point de configuration à maintenir et un vecteur d'accès à surveiller.
Groupes et synchronisation des autorisations
Les stratégies d'accès qui référencent les groupes extraient l'adhésion directement de l'IdP au moment de l'authentification. Une stratégie « autoriser : ingénierie de groupe » n'est pas une liste statique dans Cloudflare : il s'agit d'une vérification par rapport au groupe dans Okta ou Azure AD au moment où le jeton d'authentification arrive. Lorsqu'un collaborateur est ajouté ou supprimé du groupe sur l'IdP, l'effet est immédiat dès la prochaine authentification, sans synchronisation manuelle sur la plateforme Cloudflare.
Cela a une conséquence opérationnelle importante : le processus de délocalisation doit supprimer l'utilisateur de l'IdP, et pas seulement révoquer l'accès à chaque application individuelle. Si l'utilisateur est désactivé dans Okta, toutes les stratégies d'accès qui dépendent de cet IdP cessent de fonctionner pour ce compte. La session active reste valide jusqu'à son expiration, ce qui renforce l'importance de configurer des durées de session appropriées par application.
Durée de la session et application de l'AMF par application
La durée de la session est configurée par application dans Access, et non globalement. Pour une application de surveillance intérieure à faible sensibilité, sept jours sont raisonnables. Pour l'accès SSH à l'environnement de production, une session d'une heure nécessite une réauthentification fréquente, réduisant ainsi la fenêtre pour un jeton compromis. Pour un panneau d'administration de base de données, 15 minutes peuvent être plus appropriées.
L’authentification MFA peut être requise au niveau de l’accès, indépendamment de ce que fait l’IdP. Si l'IdP n'applique pas l'authentification MFA par défaut, la stratégie d'accès peut exiger l'utilisation d'une authentification à deuxième facteur — Access redirigera l'utilisateur vers l'exécution de l'authentification MFA chez l'IdP si le jeton n'inclut pas cette garantie. Différentes applications peuvent avoir différentes exigences d'assurance d'authentification sans qu'il soit nécessaire de configurer plusieurs stratégies MFA sur l'IdP.
Jetons de service pour l'accès de machine à machine
Pipelines CI/CD, agents de surveillance, webhooks : tout système automatisé qui doit accéder à une ressource protégée par accès est confronté à un problème : il n'y a aucun utilisateur humain pour passer par le flux SSO. Access résout ce problème avec des jetons de service : une paire d'ID client et de secret client qui identifie un service en tant qu'entité de confiance.
Le service automatisé inclut l'ID client dans l'en-tête CF-Access-Client-Id et le secret dans CF-Access-Client-Secret. Access reconnaît le jeton de service, évalue la stratégie associée et autorise ou refuse l'accès, générant ainsi un événement d'audit comme tout autre accès. Les jetons de service ont une date d'expiration configurable et peuvent être révoqués individuellement sans affecter les autres jetons ou utilisateurs.
Comment structurer les politiques avant d'appeler
L’erreur de conception la plus courante lors de l’adoption d’Access consiste à créer une stratégie par application sans modèle hiérarchique. Avec des dizaines d’applications internes, la gestion de politiques individuelles pour chacune d’entre elles devient une charge opérationnelle considérable. L'alternative consiste à définir des groupes d'accès réutilisables — « accès de base pour tous les employés », « accès élevé pour l'équipe d'ingénierie », « accès administratif pour SRE » — et à les appliquer sous forme de blocs dans les politiques individuelles de chaque application.
La politique d'accès d'une nouvelle application peut hériter d'un groupe de base et ajouter des conditions spécifiques, telles que la posture obligatoire de l'appareil ou des restrictions temporelles. Lorsque l’équipe d’ingénierie s’agrandit et qu’un nouveau groupe est créé dans l’IdP, la mise à jour de la stratégie de groupe réutilisable dans Access se propage automatiquement à toutes les applications qui y font référence.
Ce qui doit être décidé avant de configurer
L'intégration technique avec l'IdP est le moindre des défis. Le plus important consiste à documenter les décisions politiques et leur justification avant de permettre l'accès en production. Quelles applications ont un accès automatique pour tous les collaborateurs ? Lesquels nécessitent l’approbation explicite du groupe ? Comment sont traités les collaborateurs externes des entreprises partenaires ? Qui maintient les groupes de l’IdP alignés sur les politiques d’accès ?
Ces questions n'ont pas de réponse technique : ce sont des décisions que l'équipe de sécurité et l'équipe produit doivent prendre ensemble. Les équipes qui arrivent à la configuration technique sans avoir répondu à ces questions se retrouvent souvent avec des politiques très permissives qui reproduisent le problème du VPN avec une couche d'authentification en plus.