UAC implementation

[Zyga]

Hello,
I am just wondering - without any particular need - do you have strategies to implement UAC in your application? Any generic solution that are not tightly coupled with the architecture of the software? So far my cleanest solution is to check elevation before loading module UI, but even though the implementation is fairly simple it has limitations.
Do you have your own libraries that are applicable to different applications with different complexity or is this something which is tailored depending on client needs.

Zyga

[ShaunR]

Checking very easy (IsUserAnAdmin).

For exe's then there is the Manifest which is fairly automagic.

Edited June 20, 2022 by ShaunR

[Zyga]

That not what I have in my mind. I explain myself wrongly. By UAC I meant user access control inside application, not UAC as a Windows functionality.
Access controls like Basic User, Maintenance, Super User so on.

[Antoine Chalons]

In the past I used the DSC module from NI, it lets you create groups and users in those groups, then in any VI of your project you can hide front panel elements based on groups.

There is a palette with a few VIs to list / change users.

Pretty handy, and if you change user during execution, automagically LabVIEW handles the rules that you defined.

You can't change changes "rules" during execution.

 

DSC module is Windows only.

edit : a runtime is needed for deployed EXEs, I'm pretty sure the runtime is free, at least it was in the past.

Edited June 21, 2022 by Antoine Chalons

[ShaunR]

Oh. IC. You said UAC and "elevation" I assumed it was Windows.

I don't use terms like "Super User". They are things like Manager, Operator, Technician etc which makes more sense in a production environment.

At the core, I use a database. Sometimes users are linked to the logon credentials of Windows so they log in and out of windows to get certain access rights. Control/indicator labels have a group in the name (e.g. label_1_TECHNICIAN, Label_2_MANAGER) and are hidden/shown on change events or when loaded. However. Controls/Indicators that are not dependent on login credentials (the default-usually OPERATOR) don't have a suffix (e.g. Label_3) meaning you only have to define the exceptions, rather than everything. It's the same for dynamically loaded modules (e.g. different configuration sub-panels loaded for different access rights). The VI has the group in the name (e.g. Config_TECHNICIAN).

As you can imagine. I use captions for presentation, not labels.

Edited June 21, 2022 by ShaunR

[Gribo]

Since I work mainly in a Windows environment, I use Active Directory to get user's permissions. The organization controls the groups and user assignment - one item less to worry about.

[Rolf Kalbermatter]

On 6/21/2022 at 6:49 AM, Antoine Chalons said:

DSC module is Windows only.

edit : a runtime is needed for deployed EXEs, I'm pretty sure the runtime is free, at least it was in the past.

It definitely wasn't free last time I checked. This page would agree with that.

Also the product page would agree too. You need the Deployment license for every computer you want to run an executable that uses the DSC module.

There are a few functions of the DSC module that do not necessarily require a license. Maybe the user manager component is part of that.

Yes it is Windows only, 32-bit only and pretty much depreciated 

 

Edited June 26, 2022 by Rolf Kalbermatter

[Zyga]

Thank you for your thoughts. DSC solution seems to be easiest, still own implementation like ShaunR might be needed as I met requirement to prevent some users from using keyboard on a few controls. So this approach might be extended not only to visibility but also other properties.
 

[Antoine Chalons]

VIs from DSC / user management let you check the user/group of currently connected user and based on that you can decide to do anything you wish, refuse keyboard entry, value change on controls, etc...

To be clear, I'm not saying you should use the DSC module, I'm simply saying it could be used also to do that.

Now... do you already have a licence for it? If not, just implement your own user management.

If yes, not too fast, using it requires to understand how it stores the information about the domain (groups/users) etc.

[ShaunR]

2 hours ago, Zyga said:

So this approach might be extended not only to visibility but also other properties.

Yes. The naming is the important part so you can even use it on menus by using appropriate tags to remove or disable items.

[hooovahh]

Here's a thread on LAVA years ago with some VIs to get a list of what groups the user is in.  In the past I've had a couple of groups for various features of the software.  An admin would assign what user can do what features, and then in my software I'd just query the users access and enable things based on that.  I also used DSC years ago and it was fine, but I'd prefer Windows security since group policy can dictate things like passwords expiring, and password rules.

[Zyga]

On 6/22/2022 at 12:53 PM, Antoine Chalons said:

VIs from DSC / user management let you check the user/group of currently connected user and based on that you can decide to do anything you wish, refuse keyboard entry, value change on controls, etc...

To be clear, I'm not saying you should use the DSC module, I'm simply saying it could be used also to do that.

Now... do you already have a licence for it? If not, just implement your own user management.

If yes, not too fast, using it requires to understand how it stores the information about the domain (groups/users) etc.

Good to know, I have that license and even this is not a solution for me due to platforms limitation, I will surely check how it works. 

Cheers!