Configurer un fournisseur d'authentification

Dans Ping64, un fournisseur d'authentification définit les paramètres de connexion d'une application métier. La gestion des identités prend en charge l'authentification des applications par OAuth 2.0 / OpenID Connect (OIDC). Après sa configuration, le fournisseur doit être associé à l'application, puis les paramètres et les vérifications doivent être effectués côté application.

Un fournisseur d'authentification et une source d'identité d'annuaire ont des rôles différents : la source connecte ou gère les données d'identité ; le fournisseur sert à l'authentification des applications. Enregistrer un fournisseur ne signifie ni que l'intégration est terminée ni que tous les utilisateurs peuvent accéder à l'application.

Les libellés d'interface en gras dans ce chapitre correspondent à l'interface anglaise. Les libellés visibles peuvent varier si une autre langue est utilisée.

Si l’application cible dispose déjà d’un fournisseur approprié, vérifiez et conservez cette association. Sinon, vous pouvez choisir un fournisseur existant correctement configuré et non associé à une autre application. Un fournisseur ne peut pas être lié simultanément à plusieurs applications ; s’il est déjà utilisé, préparez-en un autre adapté sans supprimer l’association existante sans évaluation. Vérifiez les dépendances et la restauration avant toute modification de l’authentification.

Prérequis

• Utilisez un compte administrateur disposant des droits de consultation et de configuration de la gestion des identités. La suppression d'un fournisseur exige le droit d'opération correspondant.
• Confirmez avec le responsable de l'application le type de client, l'adresse de rappel de connexion, l'adresse de redirection après déconnexion, les portées nécessaires et les exigences relatives à l'identifiant utilisateur.
• Préparez une clé de signature disponible sous Certificates, une application de test et des comptes de test avec et sans accès.
• Un Client Secret est un élément d'identification sensible. Conservez-le et transmettez-le par un canal sécurisé approuvé par l'organisation ; ne l'inscrivez pas dans des tickets ordinaires, des captures d'écran ou de la documentation publique.

Créer un fournisseur

1. IAM > Authentication Configuration > Authentication Providers: Dans la console, ouvrez la gestion des identités, puis Authentication Providers sous Authentication Configuration, et choisissez Create.
2. Sous Basic Information, saisissez un nom et, si nécessaire, une description. Le nom est obligatoire.
3. Sous Protocol Settings, choisissez le Client Type : Confidential convient aux applications capables de conserver un Client Secret en sécurité ; Public convient aux clients qui ne peuvent pas conserver en sécurité un secret partagé. Confidential est sélectionné par défaut à la création ; vérifiez ce choix selon le mode réel d'intégration de l'application.
4. Vérifiez le Client ID généré automatiquement. Un client confidentiel affiche également un Client Secret. Avant de régénérer l'une de ces valeurs, évaluez l'effet sur l'accès à l'application et transmettez les nouvelles informations par un canal sûr.
5. Saisissez au moins une et au plus dix Redirect URI. Chaque adresse doit commencer par http:// ou https:// et correspondre à l'adresse de rappel de connexion réellement utilisée par l'application. Ajoutez au besoin jusqu'à dix Logout Redirect URI.
6. Sélectionnez une Signing Key disponible. Dans Advanced Protocol Settings, choisissez Scope, Subject Mode et Issuer Mode, puis confirmez-les avec le responsable de l'application. Scope limite les informations d'identité demandées ; Subject Mode influe sur l'identifiant utilisateur reçu par l'application. N'accordez pas de portées inutiles.
7. Enregistrez et vérifiez le message de réussite ou d'échec. Le retour à la liste ne prouve pas que l'enregistrement a réussi : rouvrez le fournisseur et vérifiez son nom, son Client ID, ses adresses de rappel et les autres paramètres.

Enregistrez l’adresse complète de rappel de connexion utilisée par l’application, avec son chemin, sa barre oblique finale et ses paramètres de requête. Utilisez la même adresse pour l’autorisation et l’échange du code ; le seul domaine ne suffit pas. Si l’application demande une redirection après déconnexion, enregistrez d’abord l’adresse complète correspondante dans Logout Redirect URI. Une adresse non enregistrée est refusée. Sans redirection après déconnexion, il n’est pas nécessaire d’ajouter d’adresse.

L'acceptation d'une adresse http:// par la page ne signifie pas qu'elle convient à la production ni que le transport réseau est protégé. Évaluez le transport et les adresses de rappel selon les exigences de sécurité de l'organisation.

Choisir et vérifier les portées : la page propose openid, profile, email et offline_access. La sélection définit ce qu’une application est autorisée à demander ; elle doit également demander les portées nécessaires lors de la connexion. La demande doit contenir au moins une portée et ne pas dépasser celles autorisées. Pour une connexion OIDC, sélectionnez openid selon les besoins d’intégration. Pour obtenir le nom ou l’adresse e-mail via les informations utilisateur, vérifiez que profile ou email, respectivement, est autorisé et effectivement demandé. L’adresse dépend aussi de sa présence dans le compte. offline_access concerne les jetons de rafraîchissement, mais sa sélection ne garantit pas leur utilisation : les configurations enregistrées sur cette page n’autorisent pas le mode de rafraîchissement par jeton. Les informations de découverte ou la réception d’un tel jeton ne prouvent pas qu’un rafraîchissement ultérieur réussira. Si une connexion continue est nécessaire, convenez d’une solution disponible avec le responsable de l’application et le support technique, puis vérifiez le comportement après expiration du jeton avant la mise en production.

Associer et vérifier une application

Si un fournisseur existant répond aux exigences et est déjà associé à l’application cible, ignorez les étapes 1 et 2, commencez les contrôles à l’étape 3 puis poursuivez la vérification. N’effectuez les étapes 1 et 2 que si une application doit être créée ou l’association modifiée. Avant toute modification, évaluez les effets sur les autres applications et utilisateurs et préparez un plan de restauration.

1. Ouvrez Applications sous Applications & Access, puis créez ou modifiez une application.
2. Dans le champ du fournisseur de l'application, ouvrez la fenêtre de sélection et choisissez un fournisseur applicable et disponible. Renseignez les autres paramètres nécessaires et enregistrez. Configurez le périmètre d'accès selon l'usage réel ; l'association seule n'accorde pas de droit d'accès aux utilisateurs.
3. Revenez à Authentication Providers, ouvrez les détails par le nom du fournisseur et vérifiez l'application associée, le Client ID, les adresses de rappel et les informations de configuration OpenID affichées.
4. Vérifiez d’abord les paramètres de connexion de l’application métier ; uniquement s’ils ne répondent pas aux exigences, le responsable de l’application les ajuste selon un plan approuvé. Avec des comptes de test contrôlés, vérifiez un accès autorisé et un accès refusé, puis les redirections réelles après connexion et déconnexion.
5. Vérifiez les portées demandées, l'identifiant utilisateur et la validation de signature. Contrôlez l'Issuer Mode avec le document de découverte réel, les jetons et les résultats d'intégration ; ne déduisez pas l'émetteur réel de la seule description de l'option affichée.
6. Confirmez avec le responsable de l'application qu'elle utilise le flux de code d'autorisation. Pour un client confidentiel utilisant un Secret, confirmez par un canal sûr que les configurations des deux parties correspondent. Un client public doit prendre en charge PKCE et utiliser des paramètres de vérification correspondants lors de l'autorisation et de l'échange du code ; privilégiez S256. L'authentification peut échouer si PKCE n'est pas pris en charge ou si les paramètres ne correspondent pas. Ne passez pas à un client confidentiel pour contourner l'impossibilité de stocker le Secret en sécurité.

Modifier et supprimer

Choisissez Edit pour modifier un fournisseur dans la liste. Si le Secret n'est pas régénéré lors de la modification, la page peut afficher un masque ; ne l'utilisez pas comme Secret réel. Une modification du Client ID, du Secret, des URI de redirection, de la clé de signature ou du mode d'identifiant utilisateur peut affecter les applications connectées. Prévoyez une fenêtre de changement et un plan de retour arrière, puis vérifiez à nouveau les applications associées.

Avant la suppression, identifiez les dépendances des applications et préparez leur migration. La suppression retire les associations aux applications et affecte les informations d'authentification associées ; les utilisateurs risquent de ne plus pouvoir poursuivre les flux concernés. Ne supposez pas que les associations seront restaurées automatiquement.

Dépannage

• Fournisseur introuvable : la recherche par nom peut omettre des entrées existantes. Effacez le mot-clé et vérifiez la liste et les droits du compte.
• Échec de l'enregistrement : contrôlez le nom, les adresses de rappel, la clé de signature, les portées, les autres champs obligatoires et le message affiché. Le retour à la liste ne prouve pas la réussite.
• Échec du rappel de connexion : comparez l'adresse réellement utilisée avec la configuration du fournisseur, le type de client et les paramètres de l'application. Vérifiez l'adresse complète des deux côtés.
• Jeton ou identifiant utilisateur inattendu : contrôlez Scope, Subject, l'Issuer réel et la clé de signature, puis examinez les journaux de l'application pour vérifier l'intégration.
• Connexion impossible après une modification : contrôlez l'association, le Client ID, le Secret, la clé de signature et l'état de l'application, puis suivez le plan de restauration approuvé.