How to set up permissions for a nondeveloper - domain/application user

[done11]

In the multi tenant scenario the application developed in ThingWorx will provide the facility to create the non-developer ThingWorx users i.e. domain users for the application. Once these domain users e.g. Supervisor, Viewer etc. try to login the multi-tenant application, since they do not have various design time, visibility  & run time permissions it will not allow to do any operations and users would not be able to access the functional modules. From ThingWorx Composer super user can set the design time, visibility  & run time permissions for such domain users. Here question is, does ThingWorx provides out-of-the-box feature to set the permissions for newly created domain users via service/ custom mashup program?

There will be API's and services for setting up permissions, however for that we need to manually go through all of the design/run time permission to enable for all the respective entities (Collection, Template, Thing, Service, Mashup) for each domain user, which will be lengthy and time consuming solution. Please suggest.

[posipova]

Please refer to this article, Assigning the System User through Script which can be tailored for non-system users. Currently there is no alternative out-of-the-box feature to set the permissions on newly created users via service (except for the snippets available to use in a custom server).

[akumar-10-11-12211]

Hi,

Are you able to able find the alternate method of doing this till now?

By this, I mean Assigning the System User through Script.

Regards,

Abhishek Kumar

[PaiChung]

Having gone through securing an application recently myself, I can understand the desire for features like these.

At this juncture the best way is to add security as you are building vs. finishing an application and layer security afterwards.

Since you should know the different 'type' of users ahead of time, you can create Application Security User Groups that have certain permissions that you can then stack for the actual 'Application Role User Groups'

ie.

AppDefaultPermissions User Group that can execute all necessary services to get around in the application and see default information.

Has the necessary property read

AppEditPermissions User Group that can perhaps do value edits or something like that

AppManagerPermissions User Group that can create new users etc.

then you create at the end groups like

ReadOnlyUsers

Technicians

ApplicationManagers

and you add these to the groups above (note that the permissions stack)