Multi-tenant Deployment - Everyone Access to Common Entities

[pnash]

Removing the group "Users" from the organization "Everyone" also removes rights to read entities needed to render all widgets.

Does anyone have any tips for controlling permissions/visibility for commonly used, non-solution specific entities, such as StyleDefinitions, StateDefinitions and MediaEntities?

Visibility and permissions through Shapes, Templates, Data Tables, Streams, etc. is perfect for access control to functional entities, but how would we add "Users" back to the styling and rendering entities?

I tried using the AddCollectionVisbility​ service, as a test, but without any success.  I thought I would ask the community before spending much more time on this.

[adrianpet]

Hi,

     There is an easier way to do this. All you have to do is just grant Visibility permission to that user or group for whom you want to have access. In your case you want to grant access to the default "Users" group. Now, you can do this in two ways. One is manual(in which you access each entity and from permissions you grant access to the Users group) but this will take forever. The second one is automatically with REST CALL. All you have to do is just create a service on a thing and inside that service to execute the rest call that will grant Visibility permissions to the Users group. This is an example of the script that you may use, this is for the StyleDefinitions section:

var params = {

    headers: {'Accept':'application/json-compressed','Content-Type':'application/json'} /* JSON */,

                password: "your password" /* STRING */,

                url: "http://ThingworxURL/Thingworx/StateDefinitions" /* STRING */,

                username: "your username" /* STRING */,

};

var activityData = Resources["ContentLoaderFunctions"].LoadJSON(params);

var result = activityData;

var tableLength = activityData.rows.length;

var entry=new Object();

var index=1;

for (var x = 0; x < tableLength; x++)

{

  var row = activityData.rows;

  {

        var params = {

    headers: {'Accept':'application/json-compressed','Content-Type':'application/json'} /* JSON */,

                password: "yourpassword" /* STRING */,

                url: "http://thingworx-academic-staff.ptcmscloud.com/Thingworx/StateDefinitions/"+row["_3"] +"/Services/AddVisibilityPermission?principal=Users&principalType=Group&method=post" /* STRING */,

                username: "yyourusernam" /* STRING */,

  };

var activityData2 = Resources["ContentLoaderFunctions"].PostJSON(params);

  }

}

Also, the basetype of the service should be HTML.

Thanks,

Adrian

[pnash]

Adrian

Thanks very much for the response.

Option 1 isn't really an option for us; using the Everyone organisation, even with "CustomerA", "CustomerB" user groups (rather than the "Users" group) would allow CustomerA to see CustomerA AND CustomerB entities and vice-versa.

Your script in Option 2 looks very interesting and would allow us to control visibility to entities by their group, which is what we needed. We could create a "StyleUsers" organisation (& security group), add all "CustomerX" user groups to the root node/group, then add visibility and read permissions to all media and styling collections/entities.

Sounds like a plan...

Thanks again,

Patrick

[ggupta1]

How we get the all media and styling collections/entities? is there some inbuilt service for it?

[jgorsline]

Patrick,

Any update on this? Were any of the posts in the discussion helpful? If so, could you click on the "correct answer" or "mark as helpful" button and let us know?

[keriw]

Hi,

I leveraged tagging for application of security.  I created several different tags: Base System Elements which are elements that are used by all users within the multi-tenancy environment and then I created a tagged that matched the Organization name for any elements that where organization specific.  As for Users I created two base user groups, General Users and Super Users, you could have more but for my scenario this worked.  I then created Organization specific User Groups for instance Organization 1 Users and added it as a member to the applicable matching group created earlier in this case General Users.  I then added the Organization User Groups to the applicable Organization Unit.  When I went to apply runtime users and design time users, I used the high level groups, that contained the organizational groups.  I limited access to things, mashups, etc by using Visibility.  I then created a couple of services that went and applied visibility to anything with the inputted tag, ex:

ServiceName: AddVisibilitytoBaseSystemElementsByOrganization

Inputs:

Organization (string)

BaseSystemElementVisibility (Tag)

var params = {

  organizationName: Organization /* STRING */,

  includeDependents: true /* BOOLEAN */,

  tags:BaseSystemElementVisibility

};

// no return

Resources["EntityServices"].AddEntityVisibility(params);

This allows configuration users to be able to Add new Organizations via a runtime mashup and then have a script apply the security automatically.