Nouvelles fonctionnalités spécifiques à ThingPark Enterprise auto-hébergé

Délégation de l'authentification des utilisateurs à des fournisseurs d'identité tiers RDTP-17071

À partir de ThingPark Enterprise auto-hébergé 7.1.1, l'administrateur TPE peut configurer la plateforme pour déléguer l'authentification de l'utilisateur à un fournisseur d'identité (IDP) externe qui supporte le flux d'autorisation par code OpenID Connect.

Avec cette délégation, les règles d'authentification de l'utilisateur (stockage et règles d'application des mots de passe, utilisation de l'authentification multifacteur, déconnexion de l'utilisateur...). sont gérées directement par le fournisseur d'identité tiers, pas par ThingPark.

Plus de détails

Gestion des utilisateurs dans TPE

Lorsque la fédération d'authentification est activée, les utilisateurs doivent encore être créés dans l'interface utilisateur de TPE pour avoir accès aux services de TPE. Dans ce cas, le formulaire de création d'utilisateur se limite à un e-mail et des rôles.

L'e-mail fourni lors de la création de l'utilisateur doit correspondre à l'e-mail de l'utilisateur fourni par l'IDP du client dans le jeton d'identification lors du premier accès à TPE. Cette contrainte de correspondance n'est pas requise pour les tentatives de connexion ultérieures du même utilisateur, car l’identifiant de réclamation (sub) du jeton Id est utilisé pour trouver l'utilisateur correspondant de TPE.

Remarques

• Le contenu de l'email d'activation est aussi adapté lorsque l’authentification fédérée est activée.

• Lorsque l'authentification déléguée est activée, TPE ne gère plus les mots de passe des utilisateurs, par conséquent, il n'est pas possible de changer/réinitialiser le mot de passe de l'utilisateur depuis l'interface utilisateur de TPE.

• un utilisateur authentifié sur l'IDP du client mais non déclaré dans TPE ne peut pas accéder aux services de TPE.

Comptes de service

Pour autoriser l'utilisation de DX-API lorsque l'authentification déléguée est activée, un compte de service doit être créé par l'administrateur de TPE. Pour en savoir plus, voir Intégration simplifiée avec DX-API via des comptes de service RDTP-17071.

note

L'utilisation des comptes de service lorsque l'authentification déléguée n'est pas activée est autorisée.

Principaux avantages pour les clients

Cette fonctionnalité permet une intégration plus facile de ThingPark Enterprise avec les services informatiques de l'entreprise pour offrir une authentification fédérée avec une expérience de connexion unique (SSO) à travers tous les services d'entreprise gérés par leur fournisseur d'identité, y compris les services TPE.

De plus, avec l'authentification déléguée, l'administrateur de la plateforme peut librement définir la politique d'authentification des utilisateurs sans aucune dépendance vis-à-vis de TPE.

Activation de la fonctionnalité

Intégration avec un IDP tiers

Le fournisseur d'identité (IDP) où l'authentification est déléguée doit répondre aux exigences suivantes :

• L'IDP doit implémenter OpenID Connect Core 1.0, et plus précisément le flux de code d'autorisation.

• L'IDP doit servir sa configuration à l'URL bien connue ${issuer}/.well-known/openid-configuration comme décrit dans OpenID Connect Discovery 1.0.

• L'IDP doit implémenter un point de déconnexion et fournir son URL dans la configuration comme décrit dans OpenID Connect RP-Initiated Logout 1.0.

• Les algorithmes de signature suivants sont supportés pour signer l'ID Token :

  • RS256
  • RS384
  • RS512
  • ES256
  • ES384
  • ES512
  • PS256
  • PS384
  • PS512

• La plateforme TPE auto-hébergé doit être déclarée dans l'IDP comme un client avec les propriétés suivantes :

  • Client confidentiel : l'identifiant client et le secret seront fournis dans l'en-tête d'authentification HTTP lors de l'appel du point de terminaison du jeton comme décrit dans l'OAuth2 RFC 6749 section 2.3.1.

  • Redirect-uri : https://{tpe-ocp-hostname}/auth/federation-callback

  • Les portées openid, email et profil sont autorisées.

  • Le flux de code d'autorisation est autorisé (Types de réponse : code, Types de subvention : authorization_code, refresh_token).

Pour aider à créer le client TPE dans le IDP, la définition du client au format OpenID Connect Client Metadata Description peut être téléchargée dans Cockpit.

Une fois le client TPE créé dans l'IDP, la fédération d'authentification doit être activée dans Cockpit.

Activer la délégation dans TPE

Lors de l'installation initiale de la plateforme TPE auto-hébergé, l'administrateur doit se connecter avec le compte 'install@actility.com' et suivre la première procédure d'installation. Cette procédure doit être effectuée avant d'activer la délégation d'authentification.

Voici la procédure globale pour activer l'authentification déléguée juste après l'installation de TPE :

1. Connectez-vous en utilisant le compte install@actility.com.

2. Dans la première procédure d'installation, configurez le premier compte utilisateur TPE avec l'email d'un utilisateur existant dans l'IDP externe.

3. Configurez la fédération d'authentification dans Cockpit.

4. Connectez-vous à TPE avec le même compte email utilisé à l'étape #2.

Sur une plateforme TPE auto-hébergé existante : activez la fédération d'authentification sur Cockpit.

note

Une fois la fonctionnalité activée, les utilisateurs se connectent directement dans l'IDP. Pour associer avec succès l'identité de l'utilisateur côté TPE et côté IDP, l'adresse e-mail de l'utilisateur doit correspondre des deux côtés lors de la première connexion après l'activation de la fonctionnalité.

Désactiver la délégation dans TPE

L'authentification déléguée (également connue sous le nom de fédération d'authentification) peut être désactivée à tout moment par l'administrateur TPE, via l'interface graphique Cockpit TPE. Dans ce cas :

• Tous les utilisateurs existants peuvent se connecter en utilisant leur email et le mot de passe qu'ils avaient avant d'activer la fonctionnalité de délégation.

• Si l'utilisateur a été créé alors que la fonctionnalité de délégation était déjà activée, ou si l'utilisateur ne se souvient plus de son ancien mot de passe, il devrait utiliser l'option de récupération de mot de passe (Mot de passe oublié) pour réinitialiser son mot de passe.

Flux réseau

Lorsque l'authentification déléguée est activée, le flux suivant doit être ouvert :

De	Vers	Protocole	Port	Description
TPE	IDP	HTTPS	443	Flux d'authentification OpenId Connect

note

Lorsqu'un proxy est configuré, ce flux passe par le proxy.

Limitations de la fonctionnalité

• Cette fonctionnalité ne fonctionne qu'avec des fournisseurs d'identité prenant en charge le protocole OpenID Connect. Le flux de code d'autorisation SAML n'est pas couvert par cette fonctionnalité.

• Support à distance : aucun utilisateur n'est créé lorsque la session de support à distance est ouverte. Ainsi, la fonctionnalité utilitaire de secours sur Cockpit n'est pas disponible lorsque la délégation est activée.

• Si l'utilisateur se déconnecte de l'interface graphique TPE, la déconnexion est immédiatement propagée vers l'IDP. Mais si l'utilisateur se déconnecte d'une autre application délégant son authentification au même IDP, une interface TPE associée à la session fermée (dans un autre onglet de navigateur par exemple) peut rester active jusqu'à 5 minutes, qui est la durée de vie du jeton de rafraîchissement.

Intégration simplifiée avec DX-API via comptes de service RDTP-17071

À partir de la version 7.1.1, l'administrateur TPE auto-hébergé peut créer des Comptes de Service.

Les comptes de service sont un type spécial de comptes associés aux applications.

Les comptes de service s'authentifient sur le DX-API avec leurs identifiants :

• ID client : identifiant unique du compte de service
• Secret client : mot de passe fort généré par ThingPark Enterprise

Plus de détails

Création de Comptes de Service sur l'interface TPE auto-hébergée

Les comptes de service sont gérés dans le menu Gérer > Comptes de Service dans l'interface graphique TPE :

L'administrateur doit remplir le formulaire de création et définir un identifiant client et un (des) rôle(s) à chaque compte de service.

note

Le secret client est affiché uniquement lors de la création initiale du compte de service, l'administrateur doit le copier à cette étape car il ne s'affichera plus sur l'interface graphique pour des raisons de sécurité. En cas de perte du secret client initial, l'administrateur peut régénérer un nouveau secret (également affiché une seule fois par l'interface graphique, lors de l'étape de régénération).

Utiliser le compte de service pour s'authentifier avec DX-API

Pour utiliser le DX-API, un jeton d'accès OAuth doit être émis en utilisant le point de terminaison d'authentification DX-Admin. L'identifiant et le secret client du compte de service doivent être utilisés. Par exemple, si l'identifiant client du compte de service est "tpe-api/my-service-account" et que le secret client est "my-secret", la requête suivante devrait être effectuée à DX Admin pour obtenir un jeton :

curl -X POST
-H 'Content-Type: application/x-www-form-urlencoded'
-H 'Accept: application/json'
-d 'grant_type=client_credentials&client_id=tpe-api%2Fmy-service-account&client_secret=my-secret' https://enterprise.thingpark.com/thingpark/dx/admin/latest/api/oauth/token

Avantages clés pour les clients

Le principal avantage de cette fonctionnalité est de permettre l'utilisation de DX-API lorsque l'authentification de l'utilisateur est déléguée au fournisseur d'identité du client. Pour en savoir plus, voir Délégation de l'authentification de l'utilisateur à des fournisseurs d'identité tiers RDTP-17071. Pour aborder ce scénario, seuls les comptes d'utilisateurs réels doivent être gérés par l'IDP du client alors que les comptes de service (utilisés uniquement pour l'intégration API, ne représentant pas de véritables utilisateurs) restent gérés par TPE sans être délégués à l'IDP.

Néanmoins, l'utilisation de comptes de service indépendamment de la fonctionnalité d'authentification déléguée simplifierait l'intégration de l'application du client avec les APIs TPE dans tous les cas.

Activation de la fonctionnalité

Cette fonctionnalité est désactivée par défaut. Voir la section « Description des fonctionnalités » pour en savoir plus sur la création de comptes de service.

Limitations de la fonctionnalité

Aucune.

Empreinte optimisée du troisième nœud dans le cluster de haute disponibilité RDTP-17461

En mode Haute Disponibilité (HA), TPE auto-hébergé nécessite un cluster de trois nœuds. L'architecture HA à trois nœuds garantit une fiabilité de premier ordre tout en réduisant les risques de partitionnement réseau.

Avant la version 7.1, les services TPE sont répliqués et distribués sur les 3 nœuds (à l'exception du LRC Network Server qui s'exécute uniquement sur les nœuds #1 & #2). En conséquence, le déploiement de TPE auto-hébergé HA en version 6.1 nécessite 3 nœuds identiques avec les mêmes exigences de dimensionnement matériel qu'un serveur autonome (sans haute disponibilité).

À partir de la version 7.1, au lieu de répliquer les services sur 3 nœuds, l'orchestrateur TPE auto-hébergé (Swarm ou Kubernetes) déploie les services TPE / réplique les données de la base de données uniquement sur 2 nœuds. Cependant, le troisième nœud est toujours nécessaire en tant qu'arbitre pour prévenir le partitionnement réseau et élire le nœud maître en cas de nécessité de synchronisation de la base de données.

En conséquence, les règles de dimensionnement pour TPE auto-hébergé 7.1 impliquent l'utilisation de 3 nœuds :

• 2 nœuds de machines virtuelles dimensionnés selon les règles de dimensionnement standard utilisées pour les déploiements autonomes (sans HA), c'est-à-dire en fonction du profil de dimensionnement matériel dic Pour en savoir plus, voir Dimensionnement matériel.

• 1 petit nœud de machine virtuelle hébergeant les arbitres de la base de données. Le dimensionnement de ce nœud est le même pour tous les profils de dimensionnement de trafic.

Cette amélioration est disponible pour tous les déploiements HA de TPE auto-hébergé, pour les modes d'orchestration Docker SWARM et KUBERNETES.

Plus de détails

Principaux avantages pour les clients

Cette amélioration apporte des économies de TCO aux clients de ThingPark Enterprise souhaitant déployer une architecture haute disponibilité sur site, soit sur des serveurs dédiés, soit sur une infrastructure cloud privée (AWS, Azure...).

Grâce à cette amélioration, le coût de déploiement et d'exploitation d'un troisième nœud dans le cluster HA est considérablement réduit, tout en offrant une architecture fiable tolérante aux pannes supérieure aux architectures de déploiement à 2 nœuds.

Activation de la fonctionnalité

This feature is automatically available in release 7.1.

L'amélioration n'est pertinente que pour les déploiements TPE auto-hébergé utilisant une architecture Haute Disponibilité ; par conséquent, cette fonctionnalité n'a aucun impact sur le mode de déploiement autonome de TPE auto-hébergé.

Limitations de la fonctionnalité

Aucune.