Multi-station security notes

Many installations have multiple stations. Typically, this means a Supervisor station plus one or more JACE stations. In this scenario, often the same user(s) need to access different stations. In addition, you typically create a special “station-to-station user” in each station for use in the NiagaraNetwork. Please note the following:

By convention, a station-to-station user can be named something memorable (perhaps unique to your company or even a job site), and you should carefully guard its password—as you typically assign it many “admin write” permissions. When adding this User, properties that apply to browser access are inconsequential, for example, Facets, Nav File, and Web Profile.

Do not use this account for station login! Instead, you reference this user in another station, when adding a NiagaraStation device under a NiagaraNetwork. Refer to the “Station Add notes” section in the Drivers Guide for related details.
You can use the “network user” feature to automatically replicate users among stations, and keep them centrally managed. Configuration involves two different areas of stations: UserService and NiagaraNetwork. For an overview, see Network users.
Due to security changes, you can no longer (alternatively) copy users from one station to another with any success. While this was permitted in earlier releases of NiagaraAX, it was cumbersome and inefficient when a change to such a user was needed. You can copy categories from station to station; however, note that the index property in each copied category is reset to 0, and the category has a disabled status (until you reassign the index).
Often, a user that has already logged into a station is re-challenged for login (authentication) again. This can happen when navigating from one station to another station. Depending on whether a browser user or a (full) Workbench user, it may be possible to configure stations such that a user needs to be authenticated only once (upon initial station connection).
- If a browser user (Web Workbench or Hx access), and Niagara hosts are installed on a DNS domain, you can configure stations such that browser users are authenticated only once during the same browsing session. See Domain-wide cookies authentication.
- If a Workbench user, you can configure stations such that the user is authenticated only once. See Workbench single sign-on (SSO) realm.

Domain-wide cookies authentication

This feature is available for multi-station jobs where all Niagara hosts are installed on the same DNS domain. It allows for stations that have the same user accounts (matching user credentials) to be accessed by any such user using a “domain-specified” browser connection and a single, initial, login.

To configure domain-wide cookies authentication

Perform the following in any station that may provide the initial browser connection.

To configure domain-wide cookies authentication, do the following:

Open the slot sheet of the WebService component (in the station’s Services container).
Add a new slot, naming it “cookieDomain”, leaving other fields at defaults (type baja:String).

See Using the slot sheet for details on adding a slot.
Go to the property sheet of the WebService.

In the new cookieDomain property, enter your DNS domain name (see Figure 271 for example).
Set the Single Sign On Enabled property to true, changing it from the default false.
Property Single Sign On Enabled is new starting in AX-3.7u1; it is also available in AX-3.6u4/AX-3.5u4.
Verify that the WebService’s property Authentication Scheme is set to Cookie.
In AX-3.7 and later the Authentication Scheme property defaults to Cookie Digest, for best security. However, in some cases it may be necessary to set it differently, as in this case to Cookie.
Save this configuration of the WebService.

Figure 271. Example configured WebService in AX-3.7u1

Now, if a user points his or her browser to this Niagara host using the full DNS name (for example: supervisor.metropolis.net), after station login, they can navigate using links to other stations without need for login. The credentials used in the initial login are used in other station connections.

To support the domain-wide cookies authentication feature in browsers, hyperlinks to views in other stations must reference “hostname.domain” in either an “ip ord” format or “full url” format. Using a numerical IP address instead of “hostname.domain” in hyperlinks results in a login rechallenge.Examples using “hostname.domain” (jace1.metropolis.net):

ip ord

ip:jace1.metropolis.net│fox:│station:│slot:/PxHome
full url

http://jace1.metropolis.net/ord?station:│slot:/PxHome

Providing that the WebService in the target station is using the standard HTTP port (port 80), using the “ip ord” format in hyperlinks may be best, as it works in both Workbench and web browsers. Whereas, the “full url” format works in web browsers, but produces a “Cannot display page” exception in Workbench. However, the “full url” format is required if the target station is running a non-standard HTTP port. For example, if the target station is using an httpPort of 8080, an example hyperlink would look like:

full url (specifying port)

http://jace1.metropolis.net:8080/ord?station:│slot:/PxHome

Notes on using Hosts files for domain-wide cookies authentication

A private network of JACEs and/or Supervisor may be installed on a LAN without a domain controller or local DNS server. In this case, when configuring the WebService in stations, you can specify a “virtual” (fictional) domain name. Then, in order to provide domain-wide cookies authentication, you must manually edit the “hosts” file on each LAN-connected PC at the job that needs browser access to the Niagara system. In each PC’s hosts file, you associate the same virtual domain name with the actual IP address for each Niagara host.

On most Windows PCs, the hosts file (no file extension) resides under the subdirectory “%SYSTEMROOT%\SYSTEM32\DRIVERS\ETC”, e.g. “C:\WINDOWS\system32\drivers\etc”. The hosts file is a simple text file you can edit and save with Notepad or similar editor.

For example, in the WebService of your Supervisor station you added the cookieDomain slot, and entered a virtual domain of golly.net. You also did the same thing in the station running on each of three JACEs. The static IP addresses for these four Niagara hosts are:

Supervisor 192.168.1.99
JACE A 192.168.1.85, JACE B 192.168.1.86, JACE C 192.168.1.87

So the contents of the hosts file on each PC (that needs browser access to the system) should include entries like:

127.0.0.1  localhost
192.168.1.99  supervisor.golly.net
192.168.1.85  jace1.golly.net
192.168.1.86  jace2.golly.net
192.168.1.87  jace3.golly.net

Once the hosts file is edited on a PC, you should be able to start a browser session with the URL pointed to a Niagara host by its domain name (for example: supervisor.golly.net). After initial user login, “hostname.domain” links to views in other stations should occur without being rechallenged for login again, providing of course that the same user and password exists in the target station.

It is not necessary to edit the hosts file on any Niagara platform, unless it is a PC that is also used for browser access of stations.

Workbench single sign-on (SSO) realm

A multi-station “realms” feature is also available. This allows a Workbench user to open one station (fox), then have Workbench access to other stations, without re-prompting for credentials. For example, a Px view in a station may contain widgets with hyperlinks to views in other stations.

This feature requires that the user has an account (with same credentials) on each station in the realm. Otherwise, the user will still be prompted to login. Therefore, this feature works well with the “network user” feature (see Network users for details).

The “SSO realm” feature works only for a “full Workbench” (Fox) connection to a station. It does not apply to “Web Workbench” connections, that is browser access to a station via the WebService and WbApplet.

To configure station’s realms for Workbench single sign-on

In a multi-station job, perform the following in each station, where each station must have the same “realm” name.

To configure a station’s realm, do the following:

Open the property sheet of the root-level Config component in the station.
In the “Sys Info” property, click the Facets control (>>) for the Config Facets editor.

The Config Facets editor appears.
Add a key named “realms” of type String, with the string value (whatever desired) for the realm name.

To do this in the Config Facets dialog:
1. Click the Add control.
2. In the Config Facets dialog, click the drop-down control for key and select realms.
3. In that same facet row, ensure that “Type” is String, and click in the “Value” field and type the name of the realm. Note this realm value has no literal meaning, but must be the same for all stations.
4. Click OK to add the facet.
  
  See Figure 272 for an example of the realm “shazam” being added.
Repeat this procedure for every station in the job.

Figure 272. Add key named “realms” in Facets for “Sys Info” property of the root-level Config component

Now, if a user opens a station in Workbench (enters their credentials), they can navigate using links to other stations in this realm without need for login. The same credentials used in the initial login are used in other Workbench station connections.