Utilisateur système
L'utilisateur système est un objet système dans ThingWorx, conçu pour faciliter la gestion des autorisations de service internes, tout en permettant toujours d'accorder à la couche API externe des autorisations (par utilisateur). L'emploi de l'utilisateur système est facultatif. Si l'utilisateur système n'est affecté à aucun service, ThingWorx contrôle les autorisations de l'utilisateur ayant émis la requête initiale pour chaque service encapsulé suivant.
Habituellement, lorsqu'un utilisateur appelle un service, il doit disposer des autorisations au service appelé ainsi que des autorisations à tout autre service appelé depuis le service appelé initial. Par exemple, un utilisateur exécute un service nommé GetMachineRunTimeHistory sur un objet qui appelle en interne QueryStreamEntriesWithData et GetDataTableEntryByKey. Sans l'utilisateur système, l'utilisateur qui a appelé GetMachineRunTimeHistory doit également disposer d'autorisations explicites pour exécuter QueryStreamEntriesWithData et GetDataTableEntryByKey.
Avec l'utilisateur système, si un service personnalisé est appelé depuis un service ou un abonnement (appel d'un service encapsulé) et que l'utilisateur système est autorisé à exécuter le service, l'exécution du service est autorisée indépendamment de l'utilisateur ayant initialement déclenché la séquence d'événements, de scripts ou de services. Toutefois, l'utilisateur ne peut pas appeler directement le service encapsulé lui-même (dans l'exemple ci-dessus, QueryStreamEntriesWithData ou GetDataTableEntryByKey) à moins qu'il n'y soit explicitement autorisé.
Cette pratique permet à un administrateur de verrouiller des API de surface accessibles de l'extérieur à l'aide d'utilisateurs et de groupes disposant d'autorisations d'accès explicites. Bien qu'il soit toujours recommandé de dépendre de la propagation d'utilisateurs pour encapsuler des appels de services, l'utilisateur système peut faciliter la gestion des appels de services internes du point de vue de la gestion des autorisations.
L'utilisateur système peut être ajouté au groupe Administrateurs. Cette méthode accordera les autorisations complètes à la totalité des utilisateurs sur tout élément contenu dans un appel de service. Tous les services appelés dans un service personnalisé seront exécutés, indépendamment des autorisations de l'utilisateur lançant l'appel.
L'utilisateur système n'étend pas la visibilité d'un utilisateur lors de l'interrogation d'objets. L'utilisateur système ne peut pas être utilisé pour récupérer des objets pour lesquels un utilisateur ne dispose pas d'une autorisation de visibilité. Prenons l'exemple suivant :
1. Cinq objets, T1, T2, T3, T4, T5, héritent du modèle d'objet Template1 et deux utilisateurs, User1 and User2.
2. User1 dispose d'une autorisation de visibilité sur T1 et T2, et User2 sur T4 et T5.
3. L'autorisation d'exécution de service est accordée à l'utilisateur système pour QueryImplementingThings pour Template1 et un service personnalisé nommé CallQueryImplementingThings est créé, ce qui appelle en interne QueryImplementingThings et fournit à User1 et User2 une autorisation d'exécution du service CallQueryImplementingThings.
4. Lorsque User1 exécute le service CallQueryImplementingThings, il voit T1 et T2 dans le résultat.
5. Lorsque User2 exécute le service CallQueryImplementingThings, il voit T4 et T5 dans le résultat.
 |
Il est déconseillé d'utiliser l'utilisateur système afin de contourner les mesures de sécurité ou pour réduire la nécessité de sécuriser soigneusement votre application dans sa conception et son implémentation. Conformément aux bonnes pratiques, vous devez limiter l'utilisation de l'utilisateur système à des cas spécifiques et éviter de vous en servir comme d'une solution alternative aux pratiques de propagation d'utilisateurs.
|
Exemple d'utilisateur système
Accorder à un utilisateur système le droit d'exécuter un service signifie que tous les utilisateurs pourront exécuter ce service depuis un service personnalisé, mais qu'ils ne seront pas nécessairement autorisés à appeler directement ce service. Pour une utilisation appropriée, procédez comme suit :
1. Autorisez l'utilisateur système à exécuter un service, mais limitez les autorisations de ce service pour que les autres utilisateurs ne puissent pas l'exécuter.
2. Créez un service personnalisé qui appelle ce service restreint, puis autorisez les utilisateurs à exécuter le service personnalisé, mais pas le service restreint.
3. Les utilisateurs pourront ainsi exécuter le service personnalisé, même s'ils n'ont pas l'autorisation d'exécuter le service restreint.
Pour illustrer davantage ce concept à l'aide d'un exemple, considérons le cas d'emploi suivant :
Vous souhaitez créer un service personnalisé CustomService1, grâce auxquels les utilisateurs ont accès au statut d'un appareil connecté. Pour ce faire, CustomService1 peut utiliser le service SearchDevices sur la ressource DeviceFunctions afin de rechercher tous les appareils sur la plateforme, puis filtrer les résultats pour ne renvoyer que l'appareil souhaité.
Toutefois, une vérification des autorisations est réalisée pour CustomService1, mais aussi pour chaque appel de service au sein de CustomService1. L'utilisateur doit être autorisé à exécuter le service SearchDevices pour pouvoir appeler CustomService1. Dans le cas contraire, l'appel de CustomService1 échouera. Autoriser un utilisateur à appeler SearchDevices n'est pas la solution idéale, car vous ne souhaitez pas nécessairement donner l'accès au statut de tous les appareils, mais uniquement à l'appareil concerné.
L'utilisateur système peut résoudre ce problème. Lorsqu'un service est exécuté directement, les autorisations de cet utilisateur sont vérifiées pour déterminer s'il dispose de l'autorisation appropriée. Ceci s'applique pour n'importe quel service, y compris tous les services personnalisés. Toutefois, lorsqu'un service est exécuté à partir d'un service personnalisé, deux autorisations sont vérifiées : l'autorisation de l'utilisateur et l'autorisation de l'utilisateur système. Si l'utilisateur ou l'utilisateur système est autorisé à exécuter le service dans le service personnalisé, l'exécution se produit comme si l'utilisateur disposait de l'autorisation appropriée. SearchDevices étant uniquement appelé au sein de CustomService1 et non directement, vous pouvez autoriser l'utilisateur système à exécuter SearchDevices. Lorsque l'utilisateur appelle CustomService1, les autorisations sont vérifiées. Il est alors constaté que l'Utilisateur1 ne dispose pas de l'autorisation appropriée, à l'inverse de l'utilisateur système. Par conséquent, SearchDevices sera exécuté comme si l'utilisateur disposait de l'autorisation requise. Si l'utilisateur tente d'appeler SearchDevices directement et non au sein de CustomService1, l'autorisation de l'utilisateur système ne s'appliquerait pas, l'utilisateur se voyant alors refuser l'autorisation.
