Configuration du serveur d'authentification centralisée : PingFederate
PTC prend en charge PingFederate en tant que serveur d'authentification centralisée (CAS). Le CAS gère la relation d'approbation entre les produits PTC qui participent à l'infrastructure SSO. Le CAS fait office de courtier entre les applications en autorisant les connexions utilisateur une fois qu'ils ont été authentifiés, et en émettant et en vérifiant les jetons d'accès échangés entre les fournisseurs de services et les serveurs de ressources.
Les produits PTC implémentent les éléments suivants dans l'infrastructure SSO :
1. Utilisez des assertions SAML pour authentifier les utilisateurs avec l'IdP.
2. Ensuite, une fois que l'utilisateur a été authentifié, PingFederate lui présente une page d'autorisation d'accès dans laquelle il demande à l'utilisateur s'il souhaite que ses données du serveur de ressources soient partagées avec l'application qu'il utilise.
Lorsque vous utilisez PingFederate, vous devez consulter la documentation de PingFederate. Voici quelques conseils généraux à prendre en compte lors du déploiement de PingFederate :
• Vérifiez la durée maximale pendant laquelle une session de connexion utilisateur est valide et déterminez si les mêmes valeurs doivent être utilisées dans chacune des applications participant à votre solution SSO.
• Assurez-vous que les systèmes fonctionnent avec une tolérance de différence temporelle acceptable. Si une ou plusieurs horloges système sont désynchronisées avec le CAS et si elles dépassent le temps de tolérance de différence défini dans les systèmes, la configuration génère des erreurs et empêche les utilisateurs d'être authentifiés.
Authentification fédérée
L'authentification fédérée est le processus de validation de la demande de connexion d'un utilisateur en la comparant aux informations d'identification stockées dans le fournisseur d'identité.
Dans l'architecture SSO des produits PTC, PingFederate n'authentifie pas directement les connexions utilisateur. Au lieu de cela, PingFederate doit être configuré pour rediriger les demandes de connexion utilisateur vers l'IdP de votre entreprise. L'IdP vérifie l'authenticité des informations d'identification de connexion de l'utilisateur et envoie une assertion à PingFederate indiquant que l'utilisateur a été authentifié. Ensuite, PingFederate envoie une assertion à l'application demandeuse qui indique que l'utilisateur a été authentifié, puis il autorise la connexion de l'utilisateur. Tout au long de cette transaction, PingFederate ne traite pas les informations d'identification de l'utilisateur. Lorsque le navigateur est redirigé vers l'IdP, l'échange d'informations de nom d'utilisateur et de mot de passe se produit directement entre l'agent client utilisateur (le navigateur) et l'IdP. Vous devez créer une connexion de fournisseur de services distincte pour chaque produit PTC qui achemine l'authentification des utilisateurs via PingFederate.
Dans l'exemple suivant, ThingWorx est le fournisseur de services et PingFederate est le CAS. ThingWorx utilise le protocole SAML 2.0 ouvert standard pour l'échange d'authentification entre le fournisseur de services et le fournisseur d'identité.
La procédure d'authentification est la suivante :
1. L'utilisateur tente d'accéder au fournisseur de services.
2. Le fournisseur de services génère une demande SAML pour l'utilisateur et envoie la demande au CAS.
3. Le CAS redirige la demande SAML vers l'IdP.
4. L'IdP redirige l'utilisateur vers une page d'authentification afin de fournir ses informations d'identification (par exemple, le nom d'utilisateur et le mot de passe). Une fois que l'utilisateur a spécifié ses informations d'identification, l'IdP génère une réponse SAML. Si l'utilisateur est bien authentifié, la réponse SAML inclut une assertion SAML contenant l'autorisation de l'utilisateur.
5. L'IdP redirige ensuite la réponse vers le CAS.
PTC fournit des scripts d'automatisation pour la configuration de PingFederate avec PingFederate comme IdP. Pour plus d'informations, consultez la rubrique Configuration automatique de PingFederate en tant que serveur d'authentification centralisée.
Pour les IdP tiers, vous devez configurer PingFederate dans la configuration SSO. Pour plus d'informations, consultez la rubrique Configuration manuelle de l'authentification pour les IdP tiers.
Autorisation déléguée
L'autorisation déléguée est un concept qui permet à un fournisseur de services d'exécuter des actions ou d'accéder à des ressources à partir d'un serveur de ressources au nom d'un utilisateur, sans que l'utilisateur ne partage ses informations d'identification avec le serveur de ressources.
PingFederate génère des jetons d'accès OAuth2 que les produits PTC incluent dans les requêtes de données émanant des serveurs de ressources. Les serveurs de ressources s'appuient sur le CAS pour vérifier l'authenticité des jetons d'accès. Vous devez créer des clients OAuth distincts pour chacune des applications PTC participant à des scénarios d'autorisation déléguée.
Les produits PTC protègent davantage les ressources protégées par OAuth en configurant des étendues comme mesure de protection supplémentaire. Lorsqu'un fournisseur de services envoie un jeton d'accès avec sa demande de données auprès du serveur de ressources, une étendue associée au jeton d'accès doit également être enregistrée par rapport aux données du serveur de ressources. Pour plus d'informations, consultez la rubrique Gestion des étendues dans le cadre de l'autorisation déléguée.
Dans l'exemple suivant, ThingWorx est le fournisseur de services, PingFederate est le CAS et Windchill est le serveur de ressources. ThingWorx utilise le protocole OAuth2 standard ouvert pour autoriser un fournisseur de services à accéder aux ressources de manière sécurisée, fiable et efficace.
La procédure d'autorisation est la suivante :
1. Après réception de la réponse SAML de la part de l'IdP, le CAS envoie une page de demande d'autorisation que l'utilisateur doit approuver. Le CAS utilise la page de demande d'autorisation pour obtenir l'autorisation de générer un code OAuth.
2. Une fois que l'utilisateur accorde l'accès, le CAS génère un code d'autorisation OAuth. Le CAS redirige ensuite le code de réponse et d'autorisation SAML vers le fournisseur de services.
3. Une fois que le fournisseur de services reçoit le code d'autorisation OAuth, il demande un jeton d'accès et un jeton d'actualisation de la part du CAS, à l'aide du code d'autorisation.
4. Le CAS valide le code d'autorisation et génère un jeton d'accès OAuth et un jeton d'actualisation. Le CAS envoie ensuite les deux jetons au fournisseur de services.
5. Le propriétaire des ressources (généralement l'utilisateur) demande au fournisseur de services un contenu qui nécessite des données de la part du serveur de ressources.
6. Le fournisseur de services demande le contenu du serveur de ressources au nom du propriétaire des ressources à l'aide du jeton d'accès.
7. Le serveur de ressources vérifie le jeton d'accès avec le CAS.
8. Le serveur de ressources obtient alors le contenu demandé et l'envoie au fournisseur de services.
9. Une fois le contenu reçu, le fournisseur de services le transmet au propriétaire des ressources.
Vous pouvez également implémenter l'architecture SSO avec plusieurs serveurs de ressources. Dans l'exemple, ThingWorx Navigate est le fournisseur de services, tandis que Windchill et SAP sont les serveurs de ressources.
