Protocoles de fédération et provisionnement

OIDC, OAuth et PKCE

Les clients OIDC enregistrés utilisent l’autorisation par navigateur, la sélection du compte, le consentement et les conditions d’utilisation si ces options sont configurées. L’autorisation par appareil est une interface distincte et ne remplace pas l’enregistrement du client. PKCE et les options de niveau d’assurance supérieur dépendent des règles du client et du tenant. PAR, private-key JWT, mTLS, DPoP et les profils FAPI sont soumis à des conditions : leur présence dans le code source ne signifie pas qu’ils sont activés.

1. Enregistrez pour le client l’émetteur, la redirection et les paramètres de réponse exacts.
2. Suivez le consentement et la sélection du compte, puis vérifiez l’identité et l’audience.
3. Confirmez la prise en charge de PKCE ou du niveau d’assurance dans les règles ; n’affaiblissez pas la validation pour contourner un refus.

SAML et déconnexion à distance

Les routes SAML de fournisseur de service et de fournisseur d’identité exposent les métadonnées et les parcours d’assertion par navigateur. Configurez la connexion dans l’administration SAML. Vérifiez auprès du partenaire l’émetteur, l’audience, la destination de réponse, la signature et les conditions temporelles. La déconnexion est distincte : une révocation locale ne prouve pas que les cookies ou sessions de tous les fournisseurs de services ont été supprimés.

1. Comparez les métadonnées de connexion, la clé de signature et les points de terminaison avec ceux du partenaire.
2. Testez une assertion signée et vérifiez le tenant, le sujet, l’appartenance et l’expiration.
3. Utilisez les commandes de déconnexion prises en charge et distinguez la révocation locale de la déconnexion distante.

SCIM et synchronisation d’annuaire

Le provisionnement est distinct de la fédération interactive. Les schémas SCIM et la réconciliation coexistent avec des connecteurs d’annuaire qui s’appuient sur un agent déployé chez le client et inscrit. Les importations conservent la provenance du tenant et mettent les conflits en quarantaine ; l’adresse e-mail ne suffit pas à lier des comptes. Le serveur ne fournit pas le binaire de l’agent client.

1. Enregistrez la cible du tenant et associez les attributs pris en charge ainsi que les clés d’identité immuables.
2. Lancez une synchronisation contrôlée, examinez les résultats et résolvez les éléments en quarantaine via le processus du tenant.
3. Déployez et inscrivez séparément un agent compatible avant de lancer les tâches du connecteur.

CAS, WS-Federation et RADIUS

CAS nécessite une activation explicite. WS-Federation et WS-Trust restent désactivés tant qu’un enregistrement ou une règle autorisée ne les active pas ; les vérifications du realm, de l’audience, de la réponse, de l’appartenance, de la signature et de l’expiration restent obligatoires. RADIUS utilise un agent signé facultatif, et non un écouteur sur le site. La référence maintenue privilégie RADIUS/1.1 sur TLS ou DTLS ; l’ancien UDP est réservé à la compatibilité sur réseau privé.

1. Vérifiez l’activation du protocole et l’enregistrement du client avant de tester CAS ou WS-Federation.
2. Pour RADIUS, confirmez l’agent client, le connecteur du tenant et le transport autorisé.
3. Si le protocole est désactivé ou si l’agent n’est pas inscrit, terminez la configuration au lieu de changer de protocole pour contourner les règles.

Enregistrement et identifiants

L’enregistrement du client doit rester dans le tenant et l’application qui en sont propriétaires. Les références à l’enregistrement dynamique, private-key JWT, mTLS et FAPI décrivent des contrats conditionnels, et non une activation générale. Conservez les clés privées auprès de leur propriétaire et renouvelez ou révoquez les identifiants au moyen du contrôle d’administration correspondant. Les clés d’agent ne sont pas des identifiants de client OAuth.

1. Rassemblez le propriétaire, le tenant, la redirection ou les métadonnées, les scopes et le type d’identifiant.
2. Stockez de façon sécurisée tout secret renvoyé ; renouvelez-le ou révoquez-le dans l’interface d’administration.
3. Pour inscrire un agent, générez la clé privée côté client et soumettez sa CSR.

Contrat et résolution des problèmes

Consultez /api/auth/management/openapi.json pour connaître les opérations, champs et exigences de sécurité actuels de l’API d’administration. Les notes de protocole maintenues décrivent plus précisément le comportement des connecteurs et des niveaux d’assurance. Les causes fréquentes comprennent un mauvais tenant, une redirection non enregistrée, des métadonnées ou un certificat obsolètes, un profil désactivé, une signature invalide, une mise en quarantaine SCIM ou un agent révoqué. Corrigez le périmètre de confiance concerné ; ne désactivez pas les vérifications.

1. Vérifiez le schéma OpenAPI et les exigences de sécurité de l’opération.
2. Comparez les détails d’erreur non sensibles et les valeurs enregistrées aux métadonnées actuelles du fournisseur.
3. Retestez le parcours contrôlé et confirmez l’identité ou l’état de synchronisation avant le déploiement.

Questions fréquentes

Pages associées

• Authentification unique et identité
• Administration SSO
• Gouvernance des identités et accès privilégiés
• Accès aux applications privées