The use of System User

[#1]

The system user can become a vital point for properly yet conveniently securing your application.

From the ThingWorx helpcenter:

The system user is a system object in ThingWorx. With the System User, if a service is called from within a service or subscription (a wrapped service call), and the System User is permitted to execute the service, the service will be permitted to execute regardless of the User who initially triggered the sequence of events, scripts, or services.

http://support.ptc.com/cs/help/thingworx_hc/thingworx_7.0_hc/index.jspx?id=SystemUser&action=show

A few important notes to remember:

• It is not possible to log in as a system user
• Adding a system user to the Administrators group will not grant it the administrator permissions
• Adding a system user to the Everyone organization will not grant it the same visibility

As an option, one of the posts on our community provides a script to assign all of the permissions to the system user for a one time set up:

https://community.thingworx.com/community/developers/blog/2016/10/28/assigning-the-system-user-through-script

Example:

1. Create a new template T1, several things Thing1, Thing2, Thing3

2. Create a new thing NewThing and a new user BlankUser

3. Create a service within NewThing that uses ThingTemplates[“T1"].GetImplementingThings() and give all the permissions to the new non-admin user, BlankUser

Now the service on the template T1 can be accessed through the NewThing without explicit permissions for the BlankUser but rather through the system user.

When manipulating with data (involving read/write and access to persistence provider), the BlankUser would require more than  just visibility permissions. For example, for a Stream, the following permissions would need to be set up:

1. Visibility on Stream template,StreamProcessingSubsystem, PersistenceProvider

2. Read/write permission on the Stream thing in the use case, created with the Stream template.

Similarly, for other sources of data, things, templates and resources involved need visibility and, depending on the scenario, read/write permissions on the specific template.

[asinclair]

In order to allow visibility to the System User an Organization needs to be created that includes the System User and visibility granted to that Organization. Is this what is intended? Would it make sense for the ThingWorx platform to include such an Organization?

[posipova]

For security purposes there is currently no such organization. The idea is to have the adminsitrator build that organization with the security tailored to their requirements/needs. There is a possiblity of future features to include some expansion in this area.

[asinclair]

Okay, thanks. I think I see - granting entity visibility to a "System Organization" would be almost like allowing visibility to Everyone and must be used with care to avoid exposing private/secure information to the wrong users.

[posipova]

Precisely. Besides, when building the security layer by layer, it really allows to understand the nuances and proper handling.

[posipova]

Have you assigned visibility to that organization? It's still need to be configured as any other organization.

[nmutter]

I have a question about Visibility with System user: Is 'visibility' supported officially to be also making use of System-user concept? If System user has visibility (via e.g. own org) for an entity can this entity it be indirectly referenced?

In your scenario: I give user A direct visibility for Thing1 and serviceExecute for a service S. I give System user visibility for Thing2 and property read. Now when user A calls Thing1.S which inside uses e.g. Things["Thing2"].name the property can be read. (If User A would use e.g. queryImplementingThings he wont see the Thing2 - but if referenced like above he has indirect visibility via System user.)

We are using this mechanism for like HelperThings which should not be visible to the users directly. But did not find it officially described to work? System user is only explicitly mentioned to be used for e.g. ServiceInvoke permissions. We just used it "intuitively" and it is working for visibility as well - just not sure if this is official?

Thank you