Issue with "Open tag"

[andre.buurman@carya]

Hi,

I have issues with the "open tag" function. This function tries to make an API call that requires more than access to a tag than a standard user has.

This function would typically be used to create a tag object. After opening the tag it can normally use the read tag API method to get values. It only has an authentication failure on the open method.

There are 2 side to this story:

1. The OO API used in CG LV and probably NXG (haven't checked). In this case the open method is the only way to properly configure a tag object. In case the application only requires read access to tags there is no need to use a user that has admin rights. Therefor the application would get a failure on the open method. (it calls the "<url>/nitag/v2/tags" webservice call, which seems to require "Create, modify and delete tags" rights.
2. The webVI API used in NXG. This API isn't OO allowing a work-around by just filling a cluster with the proper values and pass it to the read method. Although it would be nicer to use the open/read/close flow.

Imho there is no need for this webservice call in case the tag is opened for read-only access. The suggestion would be to either open the tag for "read/write" or "read-only" access.

PS. The dashboard editor/player shows the same issue. Creating a dashboard with a standard user and accessing a tag to e.g. chart first displays an access error and shortly thereafter it start graphing the value anyway.

Thanks.

[andre.buurman@carya]

arghhh, I had a whole rewrite of this post, which was washed down the drain by some expiring edit timer. (sigh)

I'll try to recap.

I would like to be able to distinguish between create/delete rights and access and modify rights. More specific I would like to give users access rights to read and update values (tag, property), but disallow them to create or delete tags.

Use case could e.g. be a temperature logger where the operator is allowed to change warning and alarm limits.

[MarkBlack]

Hi Andre, 

This issue is due to the Tag APIs ability to automatically create a tag if one doesn't exist. This operation requires the Create privilege. We're discussing some ways to either modify our service our the G API for tags to avoid this problem, but I do have a work-around that you can use today.

Instead of using Open Tag to get a Tag reference use the Query Tags VI. Since the Tag should already exist you will be returned a reference to that tag that you can then read or write. 

[andre.buurman@carya]

Hi Mark,

The work-around does provide tag objects without error. Thanks for pointing out this method. I overlooked it, but I see it's quite powerful.

However it doesn't solve write access to a tag for standard users, which is what I would like to achieve.

Error -251042 occurred at NI Skyline Utilities.lvlib:Execute HTTP Verb.vi:7500002

Possible reason(s):

The web server responded with error 401 Unauthorized.

Complete call chain:
     NI Skyline Utilities.lvlib:Execute HTTP Verb.vi:7500002
     NI Skyline Tag HTTP Library.lvlib:Write Tag Core.vi:730001
     NI Skyline Tag HTTP.lvclass:Write Tag Core.vi:730001
     NI Skyline Tag.lvclass:Write Tag (DBL).vi:4560001
     test Tag write access with standard user.vi

Please consider splitting these privilege options for more control.

Maybe even go so far as to differentiate between tag privileges and tag viewer privileges.

Which could also allow provide a user write access, but e.g. limited to dashboards.

Another option could be to have a shared dashboard inherit privileges of the user that created them, e.g. created by an admin and then shared.

Most important for now is that I can't fulfill my use case at this moment. Allow a standard user to write tags using a dashboard, but not via the tag viewer. 

[MarkBlack · Accepted solution]

Hi Andre, 

It is correct that we don't yet support this granular level of permission in SystemLink Server yet. I believe we can support this level of granularity in SystemLink Cloud. While SystemLink Cloud's other limitations may not meet your full application requirements it is worth seeing if it's security model supports what you are describing. The reason I want to check on this is because we have long term interest in bringing SystemLink Cloud's security model to SystemLink Server. What isn't clear to us is the timetable for performing such work and user feedback is essential to helping us determine the priority of this work relative to other features we could bring to market. 

[JoshuaP]

Have you tried configuring the NI Web Server with the following permissions.  This should hide the Tag Viewer and allow a Dashboard or VI to read and write tags.

[andre.buurman@carya]

No, I haven't. Although after evaluation it doesn't provide what I would like.

I would like the standard user to be able to use the tag viewer, but also want to prevent them from doing destructive stuff.

Thanks

I would even like it to allow me to allow privileges based on tag groups/keywords. This way I could limit tag writing to only specific tags that a standard user may change, and disallow write access to other tags.

[andre.buurman@carya]

Hi Mark,

I saw that it's different and will have a closer look and share my thoughts. 

Thanks for the insights.

[andre.buurman@carya]

Hi Mark,

If I understand correctly the cloud policy settings provide a way to set permission per webapp/dashboard.

If so, then yes I think that would make more sense than configuring it directly in the web server's configuration. It should be configurable from the portal by admins only. Unless an admin has also given another role the permission to modify permission of certain policies. (which would be an even further generalization).

[MarkBlack]

---

andre.buurman@carya wrote:

If I understand correctly the cloud policy settings provide a way to set permission per webapp/dashboard.

---

This is correct

---

andre.buurman@carya

---

...admins only. Unless an admin has also given another role the permission to modify permission of certain policies. (which would be an even further generalization).

We have a little was to go before this is fully realized. Everyone is an admin of their own SystemLink Cloud account. That "admin" can make web apps and dashboards available to others through our sharing capability and those shared documents can have limited access to tags and messages which would then limit the access of those users who are interacting with the webapp/dashboard in their browser. 

We will eventually have capability where multiple SystemLink Cloud users can collaborate over shared hosted data. As we build out this functionality features such as roles and privileges will likely be part of it. We hope to share some of our "models" on this collaboration with customers before we start writing a lot of code. We really want to make sure we are going to build the right solution.