Jump to content

SystemLink at NI Connect


Recommended Posts

7 hours ago, Rolf Kalbermatter said:

It could have been done even without the VIs having been set to use separate compiled code. In the worst case the VIs would have been compiled the first time you open a project that uses them. So what?

Inconvenient? I don't think so, at least not nearly as much as having to always chase the right drivers.

Try to develop a distributed SystemLink project where you have both both desktop and real-time targets. Every time you switch targets, you need to wait for all the ~100s of VIs to be recompiled.

Link to comment

Regarding Systemlink for Enterprises; when SystemLink came out we wanted to use the WebVI-option to provide external users/groups dashboards offering data only that user had access to. So we needed programmatic access to the user information to then only present the dashboards/data that that user should be able to see, but that was not readily available. Managing such a setup was not practical then (we wanted to just be able to create user accounts, add them to a user group and then that user would automatically (no further programming etc needed) get access to the right data only).

Has there been any movement in such a direction (Enterprise?), or would you still need to have separate system link servers to ensure restricted access / user specific content?

Link to comment
On 6/8/2022 at 3:38 AM, JKSH said:

Try to develop a distributed SystemLink project where you have both both desktop and real-time targets. Every time you switch targets, you need to wait for all the ~100s of VIs to be recompiled.

Partly valid. This driver independence should have been there before SystemLink was a thing really. It might have made SystemLink a bit harder to make work more comfortable but still. As to SystemLink itself, when it came out it had this "SliverLight" feeling to it for me. It didn't quite go as bad so far, but still.  And on top of that it is very expensive.

I do often combine desktop and multiple real-time target projects. It works of course best with compiled code separated but I have worked that way before separate compiled code was a (reliably working) fact.

Edited by Rolf Kalbermatter
Link to comment
5 hours ago, Mads said:

Regarding Systemlink for Enterprises; when SystemLink came out we wanted to use the WebVI-option to provide external users/groups dashboards offering data only that user had access to. So we needed programmatic access to the user information to then only present the dashboards/data that that user should be able to see, but that was not readily available. Managing such a setup was not practical then (we wanted to just be able to create user accounts, add them to a user group and then that user would automatically (no further programming etc needed) get access to the right data only).

Has there been any movement in such a direction (Enterprise?), or would you still need to have separate system link servers to ensure restricted access / user specific content?

I think this presentation from NIWeek 2019 may be on point here:
 

 

  • Like 1
Link to comment

The presentation seems to show that we need to implement custom user account handling...(helpful in that regard, although just browsing quickly through the video it does not seem to be a particularly secure method - sending user names and passwords(perhaps I overlooked an underlying encryption?). What we were hoping for, as far as I remember now, was that that the user account administration and logon was handled securely by SystemLink itself, and that the selection of dashboards and/or what data those had access to would then depend on the user account (then only the last part might require the G-code to know anything about the user).

Link to comment
28 minutes ago, Mads said:

The presentation seems to show that we need to implement custom user account handling...(helpful in that regard, although just browsing quickly through the video it does not seem to be a particularly secure method - sending user names and passwords(perhaps I overlooked an underlying encryption?). What we were hoping for, as far as I remember now, was that that the user account administration and logon was handled securely by SystemLink itself, and that the selection of dashboards and/or what data those had access to would then depend on the user account (then only the last part might require the G-code to know anything about the user).

I too would like something native like this. We have dashboards that we use internally that customers would also use, but there is no built in method to segment that out best I can tell. The system filter doesn't respect workspaces either (shameless idea exchange plug) which would be one potential workaround. I do recall seeing some OAuth options on a slide (ETA: see the last slide I posted above) for the enterprise version which would be a step in the right direction. I had that presentation in my recent memory because I have it somewhere in the queue of items to try when implementing a customer facing dashboard.

Edited by Jordan Kuehn
Link to comment
On 6/8/2022 at 4:02 PM, Mads said:

Has there been any movement in such a direction (Enterprise?), or would you still need to have separate system link servers to ensure restricted access / user specific content?

That would be a good question for https://forums.ni.com/t5/SystemLink/bd-p/1020 -- The NI Engineers have been reasonably engaged/accessible there.

 

Note: Advanced != Enterprise

 

 

18 hours ago, Mads said:

The presentation seems to show that we need to implement custom user account handling...(helpful in that regard, although just browsing quickly through the video it does not seem to be a particularly secure method - sending user names and passwords(perhaps I overlooked an underlying encryption?).

The 2019 presentation only shows WebVIs' ability to interact with generic web services. It does not show any SystemLink capabilities.

Even if there is underlying encryption, storing passwords as plain text in a database is extremely bad practice.

 

18 hours ago, Mads said:

What we were hoping for... was that that the user account administration and logon was handled securely by SystemLink itself

I wouldn't want this.

User management is difficult to develop, maintain, and keep secure. It would be unwise for NI to roll their own manager; they should integrate existing, tried-and-true technologies.

Currently, non-Enterprise SystemLink does use LDAP and Windows Active Directory for user management, which is good. I haven't looked closely at what new technologies are available under Enterprise (Jordan mentioned OAuth?)

 

17 hours ago, Jordan Kuehn said:

we were hoping for.... that the selection of dashboards and/or what data those had access to would then depend on the user account (then only the last part might require the G-code to know anything about the user).

If I'm not mistaken, we used to be able to specify permissions for specific Groups of users, and a WebVI could query what permissions are available to the the current logged in user.

However, NI changed the permissions management system significantly in SystemLink 19.6 which broke this, and I don't think it was ever fixed: https://forums.ni.com/t5/SystemLink/Query-SystemLink-Account-Privileges-from-a-Custom-WebVI/td-p/4103386

Edited by JKSH
Link to comment
5 hours ago, JKSH said:
12 hours ago, Mads said:

What we were hoping for... was that that the user account administration and logon was handled securely by SystemLink itself

I wouldn't want this.

User management is difficult to develop, maintain, and keep secure. It would be unwise for NI to roll their own manager; they should integrate existing, tried-and-true technologies.

Currently, non-Enterprise SystemLink does use LDAP and Windows Active Directory for user management, which is good. I haven't looked closely at what new technologies are available under Enterprise (Jordan mentioned OAuth?)

 

We do not want to roll our own, so we want SystemLink to handle it. And if NI does not want to roll their own - they can always use subcomponents that does, but to us as a user of SystemLink it would/should appear to be handled by SystemLink😉.

In our case the bulk of the users would be external clients and we would not want to handle their dashboard accounts in Active Directory...typically the user management would be handled by support engineers that would not have admin-access to AD.

I see some of these issues mentioned in the latest release note though. Perhaps it is time to have a closer look again.

Edited by Mads
Link to comment
11 hours ago, JKSH said:

Currently, non-Enterprise SystemLink does use LDAP and Windows Active Directory for user management, which is good. I haven't looked closely at what new technologies are available under Enterprise (Jordan mentioned OAuth?)

I may have misheard/misspoken here, but I thought they mentioned more open authentication methods/user management. 

 

5 hours ago, Mads said:

 

We do not want to roll our own, so we want SystemLink to handle it. And if NI does not want to roll their own - they can always use subcomponents that does, but to us as a user of SystemLink it would/should appear to be handled by SystemLink😉.

In our case the bulk of the users would be external clients and we would not want to handle their dashboard accounts in Active Directory...typically the user management would be handled by support engineers that would not have admin-access to AD.

I see some of these issues mentioned in the latest release note though. Perhaps it is time to have a closer look again.

Agreed strongly with this. With the price tag SL commands I shouldn't be making my own user management. Which is partially why I haven't implemented the method in the video I linked.

Link to comment
26 minutes ago, Jordan Kuehn said:

Which is partially why I haven't implemented the method in the video I linked.

To be clear: That NIWeek 2019 video doesn't contain any SystemLink at all.

SystemLink asks us to use its integrated 3rd-party user management tools, not to implement our own. In other words, SystemLink doesn't want us to follow that video!

I agree (and NI agrees) with y'all that we should not be rolling our own user management system. (This applies to all software, no matter what price it is)

Link to comment
17 minutes ago, JKSH said:

To be clear: That NIWeek 2019 video doesn't contain any SystemLink at all.

SystemLink asks us to use its integrated 3rd-party user management tools, not to implement our own. In other words, SystemLink doesn't want us to follow that video!

I agree (and NI agrees) with y'all that we should not be rolling our own user management system. (This applies to all software, no matter what price it is)

At risk of derailing this thread, where is the documentation for these methods? I'm aware of local windows users and LDAP. Further, you do rightly point out the difference between systemlink and webvis. My conflation is due to wanting to utilize systemlink *and* webvis to serve data and dashboards to customers utilizing the same authentication method. As noted above the workspaces have issues with filtering properly using the system filter. I am only aware of workspaces as the ability to segment out accessibility of systems to users and even then I may want to limit data views via certain dates (system is on rent with different customers at different times), but that is another can of worms.

  • Like 1
Link to comment
11 hours ago, Jordan Kuehn said:

At risk of derailing this thread,

Perhaps a mod/admin can fork this thread? (The last several posts have been about SystemLink authentication)

 

11 hours ago, Jordan Kuehn said:

where is the documentation for these methods? I'm aware of local windows users and LDAP. Further, you do rightly point out the difference between systemlink and webvis. My conflation is due to wanting to utilize systemlink *and* webvis to serve data and dashboards to customers utilizing the same authentication method.

My apologies, I just realized that I was conflating SystemLink and NI Web Server myself.

As far as I know, NI Web Server -- which can also be used for LabVIEW-based web services without SystemLink -- uses LDAP + Local Windows accounts like you said, plus Microsoft Active Directory only: https://www.ni.com/docs/en-US/bundle/ni-web-server-18.2-20.1-feature/page/choosing-an-authentication-setting.html "Regular" SystemLink hooks into the NI Web Server for authentication.

SystemLink Enterprise (the one announced at NIWeek 2022, not the older releases which were also touted as enterprise-level) uses completely different technologies, from what I gather from the presentations. I haven't been able to find any documentation for SystemLink Enterprise yet.

 

12 hours ago, Jordan Kuehn said:

As noted above the workspaces have issues with filtering properly using the system filter. I am only aware of workspaces as the ability to segment out accessibility of systems to users and even then I may want to limit data views via certain dates (system is on rent with different customers at different times), but that is another can of worms.

I don't know of a solution for this either; we'll have to see if SystemLink Enterprise offers anything. Try asking at https://forums.ni.com/t5/SystemLink/bd-p/1020

Link to comment

One big upside to the Enterprise version that I can see would be the High Availability feature as a result of the Kubernetes clusters. I'm no IT expert, but with what I know about this it seems like a very good choice to break the various components into individual clusters and allow for individually scaling them out as well as redundancy.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.