Query SystemLink Account Privileges from a Custom WebVI

[MikeMcKenzie]

I have several custom WebVIs hosted on a SystemLink server. I am able to configure privileges for these custom WebVIs via the NI Web Server Configuration utility. This allows me to control which WebVIs are displayed on the SystemLink dashboard, based on the privilege levels of the account logged into the SystemLink server.

Is it possible to query the privileges associated with the logged in account, programmatically via a WebVI?

I'm hoping to enable/disable certain WebVI functions programmatically.

I've been looking into the SystemLink HTTP API (specifically the SystemLink Auth Service, 'niauth/v1'), but haven't been able to find a method for querying or authenticating privileges. 

[JKSH]

I'd like to know the answer too: How can a SystemLink-hosted WebVI check if the current user has a particular permission?

[MarkBlack]

Hi Mike and JKSH, 

Thanks for escalating this question. This is definitely a big topic, and I don't think I can cover everything in a single forum post. I can provide an overview and also get your feedback that will help NI prioritize work to make this process simpler for WebVI developers in the future. 

As Mike pointed out, the first and most important step is making a call to niauth/v1/auth. This route returns returns all the access control info for the user calling this route (e.g. the logged in user). It will contain both the workspaces the user is a member of and the different policies associated with that user. Policy here in an internal term that roughly maps to the roles assigned to users. Within each policy is a list of resources and actions the user. 

Consider a user assigned a role that allows reading tags and accessing the tag viewer application. When calling niauth/v1/auth the following is returned:

{
    "org": {
        "id": "42b5e7ba-fcc5-4473-bdec-631bdb9987d8",
        "name": "SystemLink Server",
        "ownerId": "a1cb24d7-9998-46b1-a7d4-8ecc3e1084e0"
    },
    "policies": [
        {
            "statements": [
                {
                    "actions": [
                        "user:Read"
                    ],
                    "resource": [
                        "*"
                    ],
                    "workspace": "global"
                },
                {
                    "actions": [
                        "user:UpdateInfo"
                    ],
                    "resource": [
                        "2ea7e70e-fc94-4211-ad7e-629af3a6ebc4"
                    ],
                    "workspace": "global"
                },
                {
                    "actions": [
                        "license:Read",
                        "license:Evaluate"
                    ],
                    "resource": [
                        "*"
                    ],
                    "workspace": "global"
                },
                {
                    "actions": [
                        "policy-template:Read"
                    ],
                    "resource": [
                        "*"
                    ],
                    "workspace": "global"
                }
            ]
        },
        {
            "statements": [
                {
                    "actions": [
                        "tag:AccessWebUI",
                        "tag:QueryTagMetadata",
                        "tag:QueryTagValue",
                        "taghistory:Read"
                    ],
                    "resource": [
                        "*"
                    ],
                    "workspace": "4af34a5c-dc8f-4ba5-a4b1-4485df41fbb4"
                }
            ]
        }
    ],
    "properties": null,
    "user": {
        "acceptedToS": false,
        "created": "2021-01-26T21:56:06.947Z",
        "email": "-",
        "entitlements": {
            "entitled": "no",
            "entitlements": [],
            "evaluation": {
                "expiresOn": null,
                "used": false
            },
            "expiresOn": null
        },
        "firstName": "janedoe",
        "id": "2ea7e70e-fc94-4211-ad7e-629af3a6ebc4",
        "keywords": [],
        "lastName": "janedoe",
        "login": "janedoe",
        "niuaId": "S-1-5-21-4289670219-1679516353-4249929820-1003",
        "orgId": "42b5e7ba-fcc5-4473-bdec-631bdb9987d8",
        "policies": [
            "bf76aec4-3551-4037-a981-4911928a6efa"
        ],
        "properties": {},
        "status": "active",
        "updated": "2021-02-10T16:50:08.738Z"
    },
    "workspaces": [
        {
            "default": false,
            "enabled": true,
            "id": "4af34a5c-dc8f-4ba5-a4b1-4485df41fbb4",
            "name": "Production-Verification"
        }
    ]
}

There is a lot going on here, so I'll just focus on the critical piece that applies to the topic in this thread.

{
...
    "policies": [
        ...
        {
            "statements": [
                {
                    "actions": [
                        "tag:AccessWebUI",
                        "tag:QueryTagMetadata",
                        "tag:QueryTagValue",
                        "taghistory:Read"
                    ],
                    "resource": [
                        "*"
                    ],
                    "workspace": "4af34a5c-dc8f-4ba5-a4b1-4485df41fbb4"
                }
            ]
        }
    ],
...
}

Here we can see the specific privileges related to tags and the workspace these privileges apply. In a WebVI you might use this part of the JSON document to drive business logic to disable controls that otherwise could be used (for example) to update a tag. If this user were to attempt to update a tag the REST API would return an error (401 unauthorized).

In the internals of SystemLink we have APIs for both our frontend and backend that consumes a policy document and computes whether a user can execute some action. In the backend this process enables us to determine if the data should be returned (200 OK) or if the operation is disallowed (401 Unauthorized). On the frontend we use this process to compute whether to show an application or disable controls within the application. These APIs do not yet exist in WebVIs.

That said these APIs are just nice tools to compute whether an action can be taken given a policy document, resource ID, and action. A savvy WebVI developer could certainly build up such a capability. I eventually expect NI to produce such an API, but I don't have a timeframe as to when that would happen. 

[JKSH]

Hi Mark,

Thank you for your detailed guide. What you described sounds very close to what we're after, but I'm still missing something.

Our use-case involves creating a WebVI with multiple tiers of permissions, a bit like SystemLink Dashboards:

• A fully-privileged user can open a Dashboard and click "Edit"
• A partially-privileged user can view an existing Dashboard but can't click "Edit"
• An unprivileged user can't see the Dashboards at all

Attempts so far

1. I set up 2 privileges in my WebVI's htpriv (conf\htpriv.d\test-overview_plugin.xml😞

<?xml version="1.0" encoding="UTF-8"?>
<application name="test-overview_plugin" xmlns="urn:com:ni:web:privilege">
    <!-- Applications can have multiple localized descriptions. -->
    <description xml:lang="en">Test Overview</description>

    <privileges>
        <privilege id="ViewResource">
            <!-- Privileges can have multiple localized descriptions. -->
            <description xml:lang="en">Allows viewing the application</description>

            <!-- Default mappings for this privilege. -->
            <role id="users"/>
        </privilege>
		<privilege id="ControlValves">
            <!-- Privileges can have multiple localized descriptions. -->
            <description xml:lang="en">Allows opening and closing the valves</description>

            <!-- Default mappings for this privilege. -->
            <role id="admins"/>
        </privilege>
    </privileges>
</application>

2. I created a custom role ("Test Operator") and mapped it to a local Windows account ("basicops"):

3. I assigned the custom role to my application, so that all logged-in users can view the app but only those with the Test Operator role can access special features:

4. I then restarted the web server and used different browsers to log in as different users.

Outcomes

When I'm logged in as "basicops", /niauth/v1/auth reports an empty policy list, so I can't tell that I have the "ControlValves" privilege:

{
...
	"policies": [],
...
}

In contrast, when I'm logged in as "admin", I get some policies:

{
...
	"policies": [{
		"statements": [{
			"actions": ["*"],
			"resource": ["*"],
			"workspace": "*"
		}]
	}, {
		"statements": [{
			"actions": ["user:Read"],
			"resource": ["*"],
			"workspace": "global"
		}, {
			"actions": ["user:UpdateInfo"],
			"resource": ["f12c0c30-ee0f-4632-be57-99705e7d203a"],
			"workspace": "global"
		}, {
			"actions": ["license:Read", "license:Evaluate"],
			"resource": ["*"],
			"workspace": "global"
		}]
	}],
...
}

I know that the role mapping and the permissions have been correctly applied, because when I change the "ViewResource" priviledge from "users" to "Test Operator", then other non-admin users can no longer view the app.

System Details

Server version is SystemLink 2020 R2 (I know that the built-in SystemLink privileges have been moved to the "Security" web app, but that doesn't seem to allow configuring custom privileges)

Questions

Primary question: How do I create (and assign) custom privileges, and then query those privileges via /niauth/v1/auth?

Secondary question: What's the relationship between roles created in "NI Web Server Configuration" standalone app and roles created in the new "Security" web app? Roles that are created in one app don't appear in the other app.