Configuration du serveur d'autorisation central
Le serveur d'autorisation centralisé (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.
Voici quelques conseils généraux à prendre en compte lors du déploiement d'un CAS :
• 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.
Les produits PTC prenant en charge SSO implémentent les deux flux d'authentification suivants via l'infrastructure SSO et les protocoles standard :
• Authentification fédérée
• Autorisation : autorisation déléguée à l'aide de types d'octroi OAuth
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 du produit PTC, le serveur d'autorisation centralisé (CAS) 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 crée une assertion indiquant que l'utilisateur a été authentifié. L'authentification est implémentée à l'aide de SAML ou OIDC, selon le protocole pris en charge pour le produit PTC (consultez la rubrique Protocoles SSO pris en charge pour les produits PTC) et la configuration du client.
Une fois l'authentification confirmée, l'assertion est envoyée à l'application demandeuse en indiquant que l'utilisateur a été correctement authentifié et que la connexion est autorisée. Pendant toute la durée de cette transaction, ni le CAS, ni l'application PTC ne pourront accéder aux informations d'identification de l'utilisateur ou les gérer. Lorsque le navigateur est redirigé vers l'IdP, l'échange des informations de nom d'utilisateur et de mot de passe est réalisé directement entre l'agent client utilisateur (navigateur) et l'IdP. Vous devez créer une connexion de fournisseur de services (SP) distincte pour chaque produit PTC figurant dans la même fédération et reposant sur l'authentification des utilisateurs via le même CAS.
Les flux d'authentification SAML et OIDC standard seront suivis en fonction de la configuration SSO. Avant de la sélectionner une technologie de CAS particulière pour une configuration SSO PTC, il convient d'examiner les options prises en charge.
Le diagramme de séquence suivant illustre le flux d'authentification. Dans cet exemple, ThingWorx est le SP et PingFederate le CAS. ThingWorx utilise le protocole SAML 2.0 standard ouvert pour l'échange d'authentification entre le SP et l'IdP.
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 votre CAS dans la configuration SSO.
Autorisation déléguée (OAuth)
L'autorisation déléguée est un concept qui permet à un fournisseur de services (SP) d'exécuter des actions ou d'accéder à des ressources à partir d'un serveur de ressources (RS) au nom d'un utilisateur, sans que l'utilisateur ne partage ses informations d'identification avec le RS.
Les jetons d'accès OAuth 2 sont demandés à partir du CAS, puis utilisés dans les requêtes de données des serveurs de ressources. Les serveurs de ressources s'appuient sur le CAS pour vérifier que le demandeur est bien un utilisateur authentifié avant d'allouer les 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.
Les produits PTC prennent en charge les types d'octroi OAuth pour les clients interactifs et non interactifs. Il est important de comprendre le fonctionnement du client pour déterminer le type d'octroi à utiliser.
 |
Veillez à consulter la documentation spécifique de votre produit PTC pour confirmer les types d'octroi OAuth pris en charge.
|
◦ Interactif : l'utilisateur s'authentifie auprès du client, le client demande des ressources au nom de ce même utilisateur. L'autorisation d'accès à la ressource est basée sur l'autorisation de l'utilisateur final.
◦ Non interactif : également connu sous le nom d'interaction Machine-to-Machine (M2M). Le client est une application et doit s'identifier auprès du CAS lors de la demande d'un jeton OAuth. L'identité dans le jeton OAuth est l'identité de la machine (client ou principal de service) et n'est pas destinée à être un utilisateur humain.
Le diagramme de séquence suivant illustre le flux du code d'autorisation OAuth. ThingWorx est le SP, PingFederate est le CAS et Windchill est le RS. ThingWorx dans un client interactif configuré pour utiliser le flux de code d'autorisation du protocole OAuth2 standard ouvert afin d'autoriser un SP à accéder aux ressources de manière sécurisée, fiable et efficace, avec l'ID de l'utilisateur final pour autoriser la récupération de la ressource.
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.
D'autres technologies de CAS peuvent être configurées à l'aide de ce même flux. Il sera peut-être alors nécessaire de recourir à des étapes et des paramètres de configuration spécifiques.
Dans le cas non interactif, le flux d'informations d'identification client est utilisé pour transmettre un ID client et une clé secrète au CAS afin de récupérer un jeton OAuth. Le jeton OAuth est ensuite transmis au RS pour récupérer la ressource demandée. Le RS doit être configuré pour prendre en charge le type d'octroi d'informations d'identification client afin de pouvoir gérer le jeton OAuth et valider la demande. Dans le diagramme de séquence suivant, le flux d'informations d'identification client est représenté avec un client non interactif demandant une ressource à Windchill en tant que RS.
Vous pouvez également configurer l'architecture SSO en tant que fédération avec plusieurs fournisseurs de services et plusieurs serveurs de ressources. Les configurations de SP et RS sont gérées par un seul CAS. De cette manière, toutes les identités utilisateur sont partagées au sein de la fédération. Dans l'exemple suivant, Windchill Navigate est le fournisseur de services, tandis que Windchill et SAP sont les serveurs de ressources.
