Системный пользователь
Системный пользователь - это системный объект ThingWorx, разработанный специально для упрощения управления внутренними разрешениями сервисов; при этом разрешениями для внешнего слоя API все еще можно управлять на основе отдельных пользователей. Использование системного пользователя является необязательным. Если системный пользователь для сервиса не назначен, ThingWorx проверяет разрешения пользователя, сделавшего исходный запрос, для всех последующих вложенных сервисов.
Обычно при вызове сервиса пользователем ему необходимо иметь разрешение для вызываемого сервиса, а также разрешения для всех других сервисов, вызываемых из первоначально вызванного сервиса. Например, пользователь выполняет для вещи сервис GetMachineRunTimeHistory, внутри которого вызываются сервисы QueryStreamEntriesWithData и GetDataTableEntryByKey. Если не использовать объект системного пользователя, пользователю, вызывающему GetMachineRunTimeHistory, также потребуются явные разрешения на выполнение QueryStreamEntriesWithData и GetDataTableEntryByKey.
В случае системного пользователя при вызове пользовательского сервиса из сервиса или подписки (вызов вложенного сервиса), когда системному пользователю разрешено выполнять сервис, выполнение этого сервиса будет разрешено независимо от пользователя, который первоначально инициировал последовательность событий, сценариев или сервисов. Однако пользователь не сможет непосредственно вызвать сам вложенный сервис (в примере выше QueryStreamEntriesWithData или GetDataTableEntryByKey), если у него не будет явного разрешения.
Эта практика позволяет администратору блокировать доступные извне поверхностные интерфейсы API, используя пользователей и группы с явным предоставлением доступа. Хотя всегда рекомендуется упаковывать вызовы сервисов в зависимости от распространения пользователей, участие системного пользователя может упростить управление внутренними вызовами сервисов с точки зрения управления разрешениями.
Системного пользователя можно добавить в группу администраторов. Это позволит предоставить всем пользователям полное разрешение для всех вложенных действий при вызове сервиса - все сервисы, вызываемые из пользовательского сервиса, будут успешно выполняться независимо от наличия разрешений у вызывающего пользователя.
Системный пользователь не расширяет видимость пользователя при запросе вещей. Системный пользователь не может использоваться для загрузки вещей, на просмотр которых у пользователя нет разрешения на видимость. Рассмотрим следующий пример, иллюстрирующий это:
1. Имеется пять вещей - T1, T2, T3, T4, T5, - которые наследуют шаблон вещи Шаблон1, и существуют два пользователя: Пользователь1 и Пользователь2.
2. Пользователь1 имеет разрешение на видимость T1 и T2, а Пользователь2 имеет разрешение на видимость T4 и T5.
3. Разрешение на выполнение сервиса предоставляется системному пользователю для сервиса QueryImplementingThings для Шаблона1, и создается пользовательская служба с именем CallQueryImplementingThings, которая внутренне вызывает QueryImplementingThings и предоставляет Пользователю1 и Пользователю 2 разрешение на выполнение сервиса CallQueryImplementingThings.
4. Когда Пользователь1 выполняет сервис CallQueryImplementingThings, он в результате увидит T1 и T2.
5. Когда Пользователь2 выполняет сервис CallQueryImplementingThings, он в результате увидит T4 и T5.
* 
Не рекомендуется использовать системного пользователя для обхода системы безопасности или снижения потребности в тщательной разработке и внедрении приложения безопасности. Рекомендуется ограничивать доверие системному пользователю конкретными ситуациями использования и отказаться от использования этого инструмента в качестве общего обходного решения для метода распространения пользователей.
Пример системного пользователя
Предоставление разрешения системного пользователя на выполнение сервиса означает, что каждому пользователю будет предоставлено разрешение на выполнение этого сервиса из пользовательского сервиса, но не обязательно, что при этом будет предоставлено разрешение на непосредственный вызов этого сервиса. Правильное использование:
1. Предоставьте разрешение системного пользователя на выполнение сервиса, но ограничьте разрешения этого сервиса так, чтобы другие пользователи не имели разрешения на его выполнение.
2. Напишите пользовательский сервис, который вызывает этот ограниченный сервис, затем предоставьте пользователям разрешение на выполнение пользовательского сервиса, но не ограниченного сервиса.
3. Пользователи смогут выполнять этот пользовательский сервис, даже не имея разрешения на выполнение ограниченного сервиса.
Чтобы дополнительно проиллюстрировать эту концепцию на примере, рассмотрим следующий вариант использования.
Требуется написать пользовательский сервис, который отображает для пользователей статус определенного подключенного устройства с наименованием CustomService1. Для этого CustomService1 может использовать сервис SearchDevices с ресурсом DeviceFunctions, чтобы просмотреть все устройства в платформе, а затем отфильтровать результаты для возвращения только одного конкретного устройства.
Однако разрешения проверяются не только для CustomService1, но и для каждого вызова сервиса, выполненного в CustomService1. Пользователю потребуется разрешение на выполнение сервиса SearchDevices, чтобы успешно вызывать CustomService1, в противном случае произойдет сбой вызова CustomService1. Предоставление пользователю разрешения на вызов SearchDevices не является идеальным решением, поскольку может быть нежелательно предоставлять этому пользователю доступ к сведениям о статусе каждого устройства и требуется ограничиться только определенным устройством.
Системный пользователь позволяет решить эту проблему. При непосредственном выполнении сервиса проверяются разрешения соответствующего пользователя, чтобы определить наличие нужных разрешений. Это правило соблюдается для любого сервиса, включая все пользовательские сервисы. Однако при выполнении сервиса из пользовательского сервиса фактически проверяется два разрешения: разрешение пользователя и разрешение системного пользователя. Если пользователь или системный пользователь имеет разрешение на выполнение сервиса в пользовательском сервисе, этот сервис выполняется так, как если бы пользователь имел разрешение на его выполнение. Поскольку SearchDevices вызывается только внутри CustomService1 и не вызывается непосредственно, можно предоставить системному пользователю разрешение на выполнение SearchDevices. При вызове CustomService1 пользователем в ходе проверки разрешений будет обнаружено, что у пользователя User1 нет разрешения, но также будет обнаружено, что разрешение есть у системного пользователя. В результате сервис SearchDevices будет выполнен так, как если бы у пользователя было разрешение. Если пользователь попытается вызвать SearchDevices непосредственно, а не из CustomService1, разрешение системного пользователя не будет применяться и вызов будет отклонен.
Было ли это полезно?