System user visibility requirements

[waynelove]

I'm missing something simple here but for the life of me cannot work out what I'm doing wrong.

I have a wrapper service (GetChildConnectionsWrapped) defined on a thing that wraps the GetChildConnections service of a Organization thing.

My system user has visibility of the Organization thing, my executing user does not.

The GetChildConnections service has execute permission for the system user but not the executing user.

The GetChildConnectionsWrapped service has execute permissions for the executing user but not the system user.

When I call the wrapper service from a mashup I get the following error message in my script log....

"User does not have visibility permission for <organization>."

If I give visibility permission to the organization for the executing user then everything works.  However, from my understanding of how wrapped services are executed this should not be required.

What have I missed?

Thanks

Wayne

[ankigupta]

Hi Wayne Love​,

Does GetChildConnectionsWrapped have any reference of the organization in it?

[posipova]

Yes, your regular user would need just visibility permission to the organization - otherwise, it wouldn't  "know it exists" to put it in a simple way.

Please refer to this The use of System User

[waynelove]

Ankit Gupta - I'm not sure what you are asking, GetChildConnectionsWrapped is a simple function that takes 2 parameters Tenant & Node and then makes the following service call...

Organizations[Tenant].GetChildConnections({ name : Node })

By doing it this way the regular user does not need to directly access the Organizations collection or object and therefore does not need visibility.

Polina Osipova - Why does the regular user need visibility of the Organization?  At the point that the service on the Organization thing is being called the context of the execution has switched from the regular user to the system user.  It seems that the system user is being constrained by the regular user's visibility permissions which sort of defeats the purpose of wrapping a service call.

Or am I missing something here....?

Thanks both for responding.

Wayne

[posipova]

It's same as it would be with any other service on any other type of collection. You wouldn't need runtime or design time permission, but you would need visibility on Template for the user to see such an entity exists. Similarly, with an organization.

The use of System User

[waynelove]

Thanks.  I understand where I am going wrong.  However, I am still no closer to a solution.

I've modified my implementation to implement the following services...

ServiceA - Has execute permissions for the user

ServiceB (formally GetChildConnectionsWrapped) - Has execute permissions for the system user only.

GetChildConnectionsWrapped - Has execute permissions for the system user only.

The system user has visibility of the Organization called "OrgName".

The process flow is that the user opens a mashup that calls ServiceA.  At this point of time we are executing with the users permissions and visibility.

Service A calls Service B. At this point we change security context and continue to execute as the system user if I understand things directly.

Service B (as the system user) then calls Organizations["OrgName"].GetChildConnections({ name:Node }).

Service B will fail at this point unless the regular user has visibility of the Organization.  Given that we have switched context to the system user when we called Service B, why is this the case?  Why are the permissions & visibility settings for the system user not being used?

Thanks

Wayne

[posipova · Accepted solution]

If I'm understanding your scenario correctly, here's a diagram:

While your regular user does not need any permissions on the Service B and switching to the system user context; it still requires *visibility* of the parent entity being accessed/referred, in this case your Organization. This is how it's designed/per our architecture. Similarly in my example above, if you have a Template with three derived things and a service A that calls service B through a system user to list all derived things from that template, while no other permissions are required for the regular user, it still needs to have visibility on the Template to know such an entity exists.

[waynelove]

Thanks Polina, the information that you've provided has been very helpful.

To rephrase what you are saying, when you call a wrapped service what is happening is that rather than acutally changing the executing security context, the wrapping function of the Thingworx platform instead provides a shortcut to override the security on the execute permission for the service.  The service itself executes with the permissions and visibility of the user despite the user not having execute permissions.

You can actually see this though the log files, the executing user does not change from the normal user to the system user, despite the execution thread passing through wrapped services.

Thanks again

Wayne

[posipova]

Exactly as you worded it!