Session permissions are not gateway permissions

Ignition has more than one place to say “only certain people may do this”. They protect different things, they are not equally powerful, and the weaker one is easy to mistake for a boundary it is not.

A note on the words first

Inductive Automation uses “project security” for something specific: a Designer feature governing who may view, save and delete project resources, and who may access ones marked protected. That is an administrative control, and it explicitly does not apply to clients.

This post is about a different thing — the permissions a project applies to its own running sessions, configured in project properties, on individual views, and on component event actions. To keep those apart, the rest of this calls them session permissions.

How access is actually expressed

The vocabulary changed in 8.0, the release that introduced Perspective, and it matters because the older terms are still in wide circulation.

For Perspective, access is expressed in Security Levels granted through an Identity Provider, with Security Level Rules and User Grants deciding who receives them. Roles have not disappeared, but they appear as one branch of that tree rather than as the model itself. The classic user-source role model remains available for the Designer and for Vision. Since 8.1 either can also be pointed at an Identity Provider — and in Vision’s case the security levels are converted back into roles and zones, so roles remain its access-control model either way.

So if you are reasoning about a Perspective screen on a current gateway in terms of “which role opens this”, you are using vocabulary that describes a different part of the product. That is worth correcting before you audit anything, because it changes where you look.

Why this is not two equal halves

It is tempting to picture two independent axes: what the gateway permits and what a session permits, either of which might be strict while the other is loose. That picture is wrong in a way that matters.

Every input to session permissions is configured on the gateway. User sources, identity providers, security levels, security level rules, user grants and security zones all live there. Someone who can administer the gateway can grant themselves any level a project checks for, or open the Designer and remove the check. There is no inheritance in the sense of a gateway role silently satisfying a session check — but there is nothing stopping an administrator from arranging one.

In practice the overlap is larger still. On a deployment using the internal user source, the security level that gates gateway configuration — usually Authenticated/Roles/Administrator on a fresh gateway — is very often the same one projects check. The honest summary is that gateway administration is a superset of session authority. Session permissions constrain operators; they do not constrain administrators.

A view is not a sandbox

Here is the assumption most worth abandoning: that a screen can only do screen-shaped things.

Perspective scripting runs on the gateway, and gateway-scoped scripting functions are reachable from a session. Adding, removing or reconfiguring a database connection is available as a scripting call in Perspective session scope. So a view can absolutely change a database connection, if somebody wrote a script on it that does.

Nothing stops this by default. Ignition does give you the tools — view permissions, and security levels on the component event action itself — but it applies none of them for you. The separation between operational screens and administrative capability is a boundary you configure and maintain, not one that exists until you switch it off. Which means the question to ask of a screen is not “what is this screen for” but “what can the scripts on it reach”.

Where write authority actually lives

Session permissions govern what a person can open. They are not the mechanism that governs what a person can change in the process.

That is tag security, configured on the tags themselves, and it is the control that decides whether a write succeeds regardless of which screen it came from. A permission model built entirely on view access will happily let a user reach a tag through a screen nobody thought to restrict.

Which control, and how much of it

A reasonable first filter is whose decision the function represents. Editing a shift note or a target is an operational decision, and session permissions are the right control. Changing how the gateway behaves is the gateway owner’s decision and belongs behind gateway access.

That filter decides which control applies. It does not decide how much. A setpoint change is genuinely the operator’s decision by ownership, and if getting it wrong hurts somebody it also wants tag-level write security, a confirmation step and an audit trail. Ownership and consequence are separate questions and both need answering — a heuristic that only asks the first will under-protect exactly the actions that matter most.

This is the reasoning behind how Company News splits its own functions. Slide editing is a Perspective component governed by whatever already protects the view it sits on, because putting a safety number on a screen is an operational act. Licensing and full-library export sit behind a gateway login, because those are the gateway owner’s decisions.

The origin axis

Security zones classify gateways, computers and IP addresses into groups that can carry their own policies, adding a dimension that is neither “who is this person” nor “what may they do in this project”, but “where is this request coming from”.

In Perspective this is not abstract: zones appear alongside roles in a view’s permission dialog, so a view can require both an identity and an origin. One caveat worth knowing before you rely on it — the project stores the zone name as a string, so renaming a zone on the gateway breaks the check silently.

Questions worth asking about your own setup

Which views have no permissions configured? Empty adds no restriction of its own — it does not fall back to a stricter default, and there is no folder-level inheritance. The only thing in front of such a view is whatever the session-level permission already requires.
What can the scripts on your operational screens reach, as opposed to what those screens are for?
Is write authority enforced on the tags, or only implied by which screens exist?
Who can administer the gateway, and are you comfortable that this is a superset of every session permission you have configured?
Would you make the same call about a request arriving from outside the plant network as one from inside it?

None of these require changing anything to answer. They require looking, and the looking is worth an afternoon.

Common questions

What is the difference between gateway security and session permissions in Ignition?

Gateway security governs access to the gateway and the Designer, where configuration lives. Session permissions govern what a person can see and do inside a running Perspective session. They are not symmetric: every input to session permissions, including identity providers and security levels, is configured on the gateway, so gateway administration is effectively a superset of session authority.

Is Ignition access still based on roles?

The classic user-source role model remains available for both Vision and the Designer, and since 8.1 either can instead be pointed at an Identity Provider. In Vision the security levels are converted back into roles and zones, so roles remain its access-control model either way. For Perspective, from 8.0 onward, access is expressed in Security Levels granted through an Identity Provider, with roles appearing as one branch of that hierarchy rather than as the model itself. Ignition 8.1 extended the same model to the Gateway, Designer and Vision.

Can a Perspective view change gateway configuration?

Yes, if a script on it does. Perspective scripting runs on the gateway, and gateway-scoped scripting functions such as adding or reconfiguring a database connection are reachable from session scope. Nothing prevents it by default, though security levels can be set on the component event action itself. The separation between operational screens and administrative capability is a boundary you configure rather than one that exists until you switch it off.

What happens if a view has no permissions configured?

It adds no restriction of its own. An empty permission configuration does not fall back to a stricter default and there is no folder-level inheritance, so the only thing in front of that view is whatever the session-level permission in project properties already requires. Unconfigured views are one of the more common findings in a permissions review.

What are security zones for?

Security zones group gateways, computers and IP addresses so a policy can be applied to them, letting the origin of a request affect what is permitted rather than only who is making it. In Perspective they can be selected alongside roles in a view permission dialog. The project stores the zone name as a string, so renaming a zone on the gateway breaks the check silently.