- Tutoriel PF27 : configurez les scopes OAuth et organisez les autorisations des clients dans PingFederate.
- Concept essentiel : un scope limite les droits d’accès représentés par une demande d’autorisation ou un jeton.
- Types de scopes : utilisez des valeurs statiques pour les autorisations fixes et des valeurs dynamiques pour les modèles de ressources variables.
- Bonne pratique : séparez clairement les scopes communs, exclusifs, groupés et par défaut.
- Étape suivante : testez le comportement des scopes pendant le flux du code d’autorisation et la configuration du client.
Tutoriel PF27 : comprendre la gestion des scopes
Le contenu de ce tutoriel PF27 se concentre sur la gestion des scopes dans PingFederate et sur son rôle dans l’autorisation OAuth. Un scope représente un sous-ensemble de droits d’accès accordés à un client, à un propriétaire de ressource ou dans le cadre d’une demande d’autorisation déléguée. Plutôt que d’accorder un accès étendu à chaque client, les administrateurs peuvent définir des autorisations précises, comme l’accès à l’adresse, au profil ou à des actions administratives.
Points clés de la vidéo :
- Emplacements de la gestion des scopes dans la console d’administration PingFederate.
- Différences entre les scopes communs, exclusifs, groupés et par défaut.
- Exemples de scopes statiques et dynamiques pour les demandes OAuth.
- Influence des valeurs de scope sur le consentement et le comportement de l’autorisation.
En pratique, la valeur du scope accompagne la demande d’autorisation. PingFederate compare cette valeur aux scopes configurés pour le client et le serveur d’autorisation. Les autorisations obtenues contribuent à déterminer ce que le client peut demander et ce que l’utilisateur peut approuver.
Définissez les scopes autour des autorisations métier, et non autour de boutons individuels de l’interface. Un modèle de scopes clair est plus facile à auditer, à tester et à maintenir pour plusieurs clients.
Configuration des scopes statiques et dynamiques
PingFederate prend en charge les scopes statiques et dynamiques. Un scope statique utilise une valeur textuelle fixe, telle que read_account, address ou profile. Chaque demande de ce scope utilise le même nom et possède la même signification.
Un scope dynamique comprend un composant variable représenté par un caractère générique. Un modèle tel que read_bank_account_txn:* peut permettre à la partie variable de changer entre les demandes, selon la conception de l’autorisation et les règles de validation.
Scope statique
Utilisez une valeur fixe pour une autorisation stable. Parmi les exemples figurent address, email, phone et profile.
Scope dynamique
Utilisez un composant variable lorsque la ressource ou le contexte demandé peut changer entre les demandes d’autorisation.
Scope groupé
Regroupez des autorisations associées sous un groupe nommé afin de simplifier la configuration et l’administration des clients.
Lors de la création d’un scope, indiquez un nom explicite et une description qui explique l’autorisation. Par exemple, un scope address peut utiliser une description telle que « Accès à l’adresse », tandis qu’un scope admin peut décrire des autorisations administratives.
N’utilisez pas les scopes dynamiques uniquement pour réduire le travail d’administration. Vérifiez que la partie variable est validée et qu’elle ne peut pas accorder un accès plus large que prévu.
Configuration des scopes étape par étape
Suivez le processus ci-dessous pour créer un modèle de scopes de base dans la console d’administration PingFederate.
Ouvrir la gestion des scopes
Connectez-vous à PingFederate et ouvrez la zone du système qui contient la gestion des scopes. Examinez les entrées de scopes communs, exclusifs, groupés et par défaut existantes avant d’ajouter de nouvelles valeurs.
Créer des scopes communs
Ajoutez des noms d’autorisations fixes tels que address, email, phone ou profile. Saisissez une courte description pour chaque autorisation et indiquez que la valeur est statique, sauf si un composant variable est nécessaire.
Créer un groupe de scopes
Ouvrez les groupes de scopes communs, indiquez un nom de groupe unique et ajoutez les scopes associés. Un groupe orienté profil peut contenir les autorisations address, email et phone.
Examiner les scopes exclusifs
Utilisez les scopes exclusifs pour les autorisations qui ne doivent pas être disponibles par défaut pour un client. Le client doit être explicitement configuré pour autoriser ces valeurs.
Enregistrer et tester
Enregistrez la configuration, puis testez une demande d’autorisation avec le paramètre de scope prévu. Vérifiez que le client reçoit uniquement les autorisations configurées pour sa demande.
Le nom d’un groupe de scopes doit rester unique dans la configuration de scopes concernée. Si un nom existe déjà comme scope commun, choisissez un autre nom de groupe afin d’éviter un conflit de configuration.
Après l’enregistrement, testez à la fois un scope autorisé et un scope restreint. Vous confirmerez ainsi que la configuration du client et la politique d’autorisation appliquent bien la limite prévue.
Autorisations des clients et comportement du consentement
Les clients demandent des scopes lors de l’autorisation. PingFederate utilise les définitions de scopes configurées et les autorisations des clients pour déterminer quelles valeurs sont disponibles. Les scopes communs peuvent être disponibles par défaut, tandis que les scopes exclusifs nécessitent une autorisation explicite du client.
Les scopes par défaut entretiennent une relation particulière avec l’expérience de consentement. Ils peuvent fournir une description par défaut ou une sélection d’autorisations pour l’écran d’approbation de l’autorisation PingFederate. Si une autorisation est configurée comme valeur par défaut obligatoire, l’utilisateur peut ne pas être en mesure de la retirer de la sélection d’approbation.
Utilisez cette liste de contrôle avant de passer de la configuration aux tests :
Liste de contrôle de l’examen des scopes
- Chaque scope possède un nom unique et compréhensible
- Les descriptions expliquent l’autorisation en termes simples
- Les modèles de scopes dynamiques disposent d’une stratégie de validation définie
- Les scopes exclusifs sont activés uniquement pour les clients concernés
- Le comportement du consentement a été testé avec des demandes d’autorisation réalistes
Conservez des noms de scopes cohérents entre les clients, les politiques et les mappages de jetons d’accès. Une convention de nommage fondée sur la ressource et l’action, telle que read_account ou write_profile, facilite l’interprétation des journaux d’autorisation.
Traitez les autorisations par défaut avec prudence. Une configuration pratique du consentement doit néanmoins rendre l’accès demandé compréhensible pour le propriétaire de la ressource et approprié pour le client.
Stratégie de test et FAQ
Un flux de travail PF27 fiable se termine par des tests ciblés. Commencez par un scope statique simple, puis testez un groupe de scopes, un scope exclusif et un scope dynamique si votre déploiement en nécessite un. Consignez la valeur demandée, l’identité du client, le résultat du consentement et les autorisations finales du jeton.
Vérifiez les résultats courants suivants :
- Un scope manquant peut indiquer que le client n’est pas autorisé à le demander.
- Le rejet d’un scope dynamique peut indiquer un composant variable non valide.
- Une sélection de consentement inattendue peut être due à la configuration des scopes par défaut.
- Un jeton trop large peut indiquer qu’un groupe contient davantage d’autorisations que prévu.
- Un nom en double peut empêcher l’enregistrement d’un groupe ou d’un scope.
Q: Qu’est-ce qu’un scope dans PingFederate ?
Un scope est une limite d’autorisation nommée qui représente un sous-ensemble précis de droits d’accès demandé par un client et évalué lors de l’autorisation.
Q: Quelle est la différence entre les scopes statiques et dynamiques ?
Un scope statique utilise une valeur fixe, tandis qu’un scope dynamique comprend un composant variable qui peut changer entre les demandes d’autorisation.
Q: Quand faut-il utiliser un scope exclusif ?
Utilisez un scope exclusif pour les autorisations sensibles qui ne doivent pas être disponibles par défaut pour les clients. Le client concerné doit être configuré pour l’autoriser.
Q: Pourquoi le nom d’un groupe de scopes peut-il ne pas être enregistré ?
Le nom d’un groupe de scopes peut ne pas être enregistré s’il entre en conflit avec un nom de scope existant ou s’il enfreint les règles d’unicité de la configuration PingFederate actuelle.
Commencez avec l’ensemble d’autorisations le plus réduit permettant de répondre aux besoins du client. N’ajoutez des scopes que lorsque le besoin de l’application est clairement établi et que le test d’autorisation confirme le résultat attendu.