Security in Vision
Security in Vision is managed through one of two authentication strategies, either the Classic Authentication strategy or Identity Providers (IdP) strategy. Classic Authentication Strategy involves a concept known as a User Source, which is a configuration that contains multiple roles and users. IdPs allow users to authenticate against a trusted third party. Refer to Security for more information on these authentication strategies.
Selecting an Authentication Strategy​
The strategy used by any given project is determined by the Authentication Strategy, found under Project Properties. See Vision Project Properties for more information.
Client Authentication Strategies​
Users are given access based off of the Authentication Strategy the project is set to.
Classic Strategy​
When using the classic strategy, a User Source needs to be assigned to the project. Users and roles are taken from the assigned User Source.
When utilizing this strategy, the Required Client Roles field can be used to limit access to the entire Vision Client based on a roles requirement.
Identity Provider Strategy​
When using the identity provider strategy, an Identity Provider needs to be assigned to the project. Users are taken from the assigned IdP.
Vision's access control model is based on roles and security zones. Thus, the Authenticated/Roles... and SecurityZones/... security levels in the IdP are converted into roles and zones, respectively. As a result, IdPs need to have user attribute mapping configured for a given IdP before Vision can utilize role based access.
Vision Client Permissions​
Every project's clients are governed by a set of permissions to control what is allowed to originate from the client. For example: access to construct queries against the database, or the ability to edit Users and Roles in your authentication profile. To maintain a secure system, these are all set to disabled by default, but you can enable them for everyone, for specific users, or even for specific users that are logged into certain zones. See descriptions of these categories and how to change them on the Project Permissions page.
Role-Driven Client Security​
On the simplest level, security settings can be applied to individual windows or components. Users with different roles can all view the same project from the client, but the functionality and readability can change based on the roles assigned to each user. Generally, higher level access provides full functionality to all contents of a project, and lower level access is restricted to generalized read-only privileges.
Below, we see the Security Settings panel in action. This panel is the interface that applies Ignition's built-in security settings. Security settings can be applied to a single component, multiple components simultaneously, or even a whole window. Users who should be allowed full access can be selected, and restrictions can be applied for users that should not have full access.
Incorporating Scripting into Security​
The component-based security settings are fairly simplistic: the user either has the required roles, or a restriction is applied. In situations where consideration for access should go beyond a simple role check, security-based scripting can provide a larger degree of granularity. Information about the logged-in user, such as user-name or roles, can be detected by scripting, allowing for the creation of a robust security system.
