This lesson is part of the Security in Ignition course. You can browse the rest of the lessons below.


Autoplay Off
Take topic challenge

Supplemental Videos


Client Permissions


Client Permissions allow you to restrict certain features in a Vision project, only providing the functionality to users under certain conditions.

Video recorded using: Ignition 8.0


(open in window)

[00:00] Ignition has a security mechanism called vision permissions, these permission rules can be found by going up to the project properties and go into the permissions section under vision. Here we have a list of actions that can be done from the client that interact with the gateway in some way. Because these can interact with the gateway, they can be seen as harmful to the security of your system. If the checkbox next to the action is not checked, then this permission is disabled, what this means is that an user will not be able to do this particular action within the client, so for example, the tag editing permission allows you to add, remove, or modify a tag when you're in the client. Disabling this action will block any client side tag modifications. One of the most important things to understand about these permissions is that by default, all of them will be disabled in a new project, this means that when making a new project, certain things that you're used to doing on a regular basis might not be allowed, until you come into this window and enable its security permission. In addition to enabling one of these actions, you can also set up required client roles here in the text field next to the action itself. Leaving the field blank, will allow anyone to perform that specific action. Or I can start entering in one of my user roles and select it from the drop down here, the user must have this role to be able to perform this action. In addition to listing user roles, I can also list a user role, and pair it with a security zone using the syntax user role name,@, and the security zone name. If I needed to, I can also select multiple user role and security zone combinations, by separating each one with a comma, this allows you to fine tune exactly how the security in your client, is going to work for these particular actions. Let's take a look at an example of how we might use the legacy database access permission. The legacy database access allows you to run standard SQL queries, for both bindings and scripting, while it's disabled, the only SQL queries that are allowed to run are those from transaction groups and those that use name queries. I'm going to leave it disabled for now, and go ahead and cancel out of here and open up a window that I have created already, you'll notice that I have a table, and if I go to the property editor on the data property, we'll see that it's just using a standard SQL query. Now, even though legacy database access was disabled, it still works here in the designer, because those permissions only affect the client, not the designer, this allows you to configure security, and still work freely within the designer. If I close this and go over to my client, once I log in, you'll notice that when you take a look at the table, it'll have a red overlay, this lets us know that we don't have permission to actually run that type of SQL query, this is because when legacy database access is disabled, nobody's allowed to use legacy database access of standard SQL query bindings from a client, however, if I were to go back into my designer, and go into the project properties once more, and enable legacy database access, after saving my project, I can come back to my client, update it, and you'll notice that now the SQL query binding works as intended. These client permissions allow you to finely tune what actions users can do from the client that affect the gateway, giving you more control over the security of your system.

You are editing this transcript.

Make any corrections to improve this transcript. We'll review any changes before posting them.


Share this video