Ignition Perspective assigns a session to Gateway Security Zones from the source address visible at the Gateway. The request path is therefore the first diagnostic: browser workstation → Ethernet path → Gateway listener. If an intermediary replaces the source address, zone matching uses that intermediary address. In the reported direct topology, the client and Gateway share a switch, yet SecurityZones remains empty. That narrows the investigation to the actual session values, the address presented to the Gateway, and the configured zone ranges.
Which access-control approach fits the requirement?
The requirement contains two independent conditions: the authenticated user must have an authorized role, and the physical workstation must belong to an authorized address range. Neither condition alone supplies strict Role + Zone control.
| Approach | Identity check | Workstation check | Failure mode | Use |
|---|---|---|---|---|
| Role only | User roles | None | An authorized user receives the same controls from every workstation | Not sufficient for localized controls |
| Security Zone only | None | Source IP visible to the Gateway | Any qualifying session could satisfy the location condition | Useful only when identity is irrelevant |
| Role + Security Zone | User roles | Gateway zone membership | Access fails closed when either input is absent | Recommended for this requirement |
Implement the decision as a logical AND: authorized role AND authorized zone. Keep the two inputs separate while diagnosing them. A combined expression can return false without showing whether authentication, address classification, or property propagation failed.
Where does the Security Zone decision occur?
Follow the packet. The browser opens a connection toward the Gateway, and the Gateway classifies the source address it sees. A Security Zone cannot recover an address that an upstream device has already translated or replaced.
| Path element | Address relevant to classification | Diagnostic question |
|---|---|---|
| Perspective workstation | Address assigned to the client interface used for the route | Which interface and address originate the Gateway connection? |
| Switching path | Normally preserves the IP source address | Is the connection actually direct, or does its route leave the local path? |
| NAT, proxy, tunnel, or other intermediary | May substitute an intermediary address | Does the Gateway see the workstation address or a shared address? |
| Gateway | Observed connection source | Does that address fall inside a configured Security Zone range? |
Layer one first: verify link state, the active client interface, its assigned address, and the route used to reach the Gateway. Then inspect the IP layer. Being connected to the same switch makes source translation less likely, but it does not prove that the browser request follows a direct path. Multiple interfaces, host routing, proxies, virtual networking, and remote-session arrangements can change where the browser actually runs or how it reaches the Gateway.
No application expression can correct a mismatched source address. Fix the network path or map the address that the Gateway truly observes.
Why can SecurityZones remain empty?
An empty SecurityZones value means the session has no usable zone membership at the point being inspected. Separate four recurring causes before changing access logic.
| Observation | Likely cause | Deciding check |
|---|---|---|
| All live sessions show empty membership | Zone configuration does not match the addresses reaching the Gateway | Compare the Gateway-observed source address with every configured range |
| Several workstations appear under one address | NAT or an intermediary hides individual client addresses | Trace the connection path and inspect the source at the Gateway |
| Designer testing differs from a launched session | The Designer substitutes authentication context | Read the properties in an actual client session |
| Role checks pass while zone checks fail | Authentication is valid, but location classification is empty or mismatched | Display role and zone inputs independently |
Do not debug this from a single visibility result. A hidden component only proves that the final Boolean result is false. Expose each security-relevant session input temporarily so the failed condition is visible.
How should the live session be instrumented?
Place diagnostic labels on a shared docked view so they remain visible while navigating among protected views. Bind the labels to the security-relevant session properties already used by the project, including the authenticated role information and SecurityZones. Use this only as commissioning instrumentation; remove or restrict it after validation because it exposes access-control context.
- Launch the Perspective project as a real client session from the target workstation. Do not treat Designer preview values as authoritative.
- Display the current role result and
SecurityZonesseparately. - Record the workstation address on the interface that routes to the Gateway.
- Determine the connection source address observed at the Gateway.
- Compare that observed address with the configured zone ranges, including range boundaries and any overlapping definitions.
- Repeat from one workstation inside the intended range and one outside it.
If the Gateway observes the intended client address but membership remains empty, correct the Security Zone address definition. If it observes another address, correct the path or base the design on a trustworthy location signal that survives that path. Widening a zone to include a shared NAT address grants the same location classification to every client behind that address.
How should strict Role + Zone access be applied?
After both inputs work independently, combine them at every relevant decision point. The authorization rule is:
allow = authorized_role AND authorized_zone- Define the authorized roles for the localized control.
- Define the Security Zone range from the address the Gateway actually receives.
- Confirm a live session populates both inputs independently.
- Apply the AND rule to navigation and view access decisions.
- Apply the same rule to control actions that change equipment state. Hiding a component is presentation behavior, not a complete authorization boundary.
- Make missing, empty, or unexpected zone membership evaluate to denied access.
Avoid an OR condition between role and zone; it permits either an authorized user at the wrong workstation or an unauthorized identity at the right workstation. Avoid using the workstation address as identity. IP classification supplies location context, while authentication supplies user identity.
How is the configuration verified?
Test the security matrix rather than one successful login. Use the same deployed project path for every case.
| User role | Zone membership | Expected result |
|---|---|---|
| Authorized | Authorized | Localized view and permitted controls available |
| Authorized | Empty or unauthorized | Denied |
| Unauthorized | Authorized | Denied |
| Unauthorized | Empty or unauthorized | Denied |
- Open a fresh client session on an in-zone workstation and confirm
SecurityZonesis populated as expected. - Authenticate with an authorized role and verify access succeeds.
- Use an unauthorized role on the same workstation and verify access fails.
- Move to an out-of-zone workstation, authenticate with the authorized role, and verify access fails.
- Retest through every production connection path that may introduce translation or proxying.
- Confirm direct navigation and equipment-changing actions enforce the same Role + Zone result as component visibility.
FAQ
Can I restrict an Ignition Perspective view by workstation IP?
Yes. Classify the source IP visible to the Gateway with a Security Zone, then combine zone membership with the user's authorized role.
Does a NAT connection preserve the Perspective client IP?
No. The Gateway sees the NAT device's translated address, so multiple workstations can receive the same zone classification.
Can I validate SecurityZones in the Designer?
Use an actual launched client session. Display SecurityZones and the role input on a temporary shared docked view because Designer authentication substitution can differ from live-session values.
Does hiding a Perspective control fully enforce access?
No. Verify the Role + Zone AND rule on view navigation and equipment-changing actions, then finish by testing all four authorized/unauthorized role-and-zone combinations.