Usuario del sistema
El usuario del sistema es un objeto del sistema en ThingWorx, diseñado para facilitar la gestión de permisos internos de servicio, mientras se permite que los permisos de la capa externa de la API se concedan según el usuario. El usuario del sistema es opcional. Si no se asigna el usuario del sistema a un servicio, ThingWorx verificará los permisos del usuario que ha realizado la solicitud original para todos los servicios empaquetados posteriores.
Normalmente, cuando un usuario llama a un servicio, debe tener permiso para el servicio llamado, así como permiso para cualquier otro servicio que se llame dentro del servicio llamado inicialmente. Por ejemplo, un usuario ejecuta un servicio denominado GetMachineRunTimeHistory en una cosa que llama internamente a QueryStreamEntriesWithData y GetDataTableEntryByKey. Sin utilizar el usuario del sistema, el usuario que ha llamado a GetMachineRunTimeHistory también necesita permisos explícitos para ejecutar QueryStreamEntriesWithData y GetDataTableEntryByKey.
Con el usuario del sistema, si se llama a un servicio personalizado dentro de un servicio o una suscripción (una llamada de servicio empaquetada) y el usuario del sistema tiene permitido ejecutar el servicio, se permitirá ejecutar el servicio independientemente del usuario que ha activado inicialmente la secuencia de eventos, scripts o servicios. Sin embargo, el usuario no podrá llamar directamente al servicio empaquetado (del ejemplo anterior, QueryStreamEntriesWithData o GetDataTableEntryByKey a menos que se le conceda permiso explícito).
Esta práctica permite a un administrador proteger la seguridad de las API de superficie accesibles externamente mediante usuarios y grupos con activación explícita de acceso. Aunque siempre se recomiende depender de la propagación de usuario para empaquetar llamadas de servicio, el usuario del sistema puede facilitar la gestión de llamadas internas de servicios desde la perspectiva de gestión de permisos.
El usuario del sistema se puede añadir al grupo de administradores. Al hacerlo, se concederá a todos los usuarios el permiso completo para todos los elementos anidados dentro de una llamada de servicio (todos los servicios invocados dentro de un servicio personalizado se ejecutarán, independientemente de los permisos del usuario que los invoque).
El usuario del sistema no expande la visibilidad de un usuario al consultar cosas. El usuario del sistema no se puede utilizar para recuperar cosas para las que un usuario no dispone de permiso de visibilidad. Tenga en cuenta el siguiente ejemplo, que ilustra esto:
1. Hay cinco cosas, T1, T2, T3, T4, T5, que heredan la plantilla de cosa Template1 y existen dos usuarios, User1 y User2.
2. User1 tiene permiso de visibilidad sobre T1 y T2, y User2 tiene permiso de visibilidad sobre T4 y T5.
3. Se concede permiso de ejecución de servicios al usuario del sistema para QueryImplementingThings para Template1 y se crea un servicio personalizado denominado CallQueryImplementingThings, que internamente llama a QueryImplementingThings y proporciona el permiso de ejecución de servicios a User1 y User2 para el servicio CallQueryImplementingThings.
4. Cuando User1 ejecuta el servicio CallQueryImplementingThings, verá T1 y T2 en el resultado.
5. Cuando User2 ejecute el servicio CallQueryImplementingThings, verá T4 y T5 en el resultado.
 |
No se recomienda utilizar el usuario del sistema para pasar por alto la seguridad o para reducir la necesidad de diseñar e implementar cuidadosamente una aplicación segura. La práctica recomendada aconseja que se debe limitar la confianza en el usuario del sistema a casos prácticos específicos y no utilizarse como solución alternativa general a las prácticas de propagación de usuario.
|
Ejemplo de usuario del sistema
La concesión de un permiso de usuario del sistema para ejecutar un servicio significa que se concederá a cada usuario permiso para ejecutar dicho servicio desde un servicio personalizado, pero no necesariamente se le concederá permiso para llamar a tal servicio directamente. Para utilizarlo correctamente:
1. Conceda el permiso de usuario del sistema para ejecutar un servicio, pero restrinja los permisos del servicio para que otros usuarios no tengan permiso para ejecutar el servicio.
2. Escriba un servicio personalizado que llame a dicho servicio restringido y, a continuación, conceda a los usuarios permiso para ejecutar el servicio personalizado, pero no el servicio restringido.
3. Los usuarios podrán ejecutar el servicio personalizado, aunque no tengan permiso para ejecutar el servicio restringido.
Para ilustrar este concepto con un ejemplo, se puede tener en cuenta el siguiente caso de uso:
El usuario desea escribir un servicio personalizado donde se muestre a los usuarios el estado de un dispositivo conectado concreto, denominado CustomService1. Para ello, CustomService1 puede utilizar el servicio SearchDevices en el recurso DeviceFunctions para ver todos los dispositivos en la plataforma y, a continuación, filtrar los resultados para devolver solo el dispositivo concreto.
Sin embargo, los permisos se comprueban no solo para CustomService1, sino para cada llamada de servicio realizada en CustomService1. El usuario necesita permiso para ejecutar el servicio SearchDevices y llamar correctamente a CustomService1. De lo contrario, la llamada a CustomService1 falla. Conceder al usuario permiso para llamar a SearchDevices no es ideal, puesto que es posible que no desee que el usuario tenga acceso al estado de todos los dispositivos, sino solamente al dispositivo concreto.
El usuario del sistema puede resolver esto. Cuando se ejecuta un servicio directamente, los permisos de dicho usuario se comprueban para determinar si tiene permiso. Esto es así para cualquier servicio, incluidos los servicios personalizados. Sin embargo, cuando se ejecuta un servicio desde un servicio personalizado, en realidad se verifican dos permisos: el permiso del usuario y el permiso del usuario del sistema. Si el usuario o el usuario del sistema tienen permiso para ejecutar el servicio dentro del servicio personalizado, el servicio del interior se ejecuta como si el usuario tuviera permiso para ejecutarlo. Puesto que a SearchDevices solo se llama desde el interior de CustomService1 y no directamente, se puede conceder permiso al usuario del sistema para ejecutar SearchDevices. Cuando el usuario llame a CustomService1, se realizará la verificación de los permisos y se verá que el Usuario1 no tiene permiso y que el usuario del sistema tiene permiso. Como resultado, SearchDevices se ejecutará como si el usuario tuviera permiso. Si el usuario intentase llamar a SearchDevices directamente y no desde el interior de CustomService1, el permiso del usuario del sistema no se aplicaría y se denegaría el permiso al usuario.
