Enabling User Management and Secure Data Connection in The Collectors Utilizing Pulse

What a 2.0 installation already does#

The Collector ships secured on both sides. Its settings.config has Pulse:Auth:Enabled set to true and names its Pulse client as Collector, so people sign in to the Collector through Pulse. Its shipped historians.config carries one Historian link, to localhost:4512 over TLS, whose Authentication is This host: the Collector presents its own Collector identity when it writes data. The seeded Collector client in Pulse carries the Historian among its audiences, so the Historian accepts it.

So on a fresh installation the one step is the Collector's client secret. HTTPS and certificates are automatic through Pulse:Cert; see Timebase Certificates.

Give the Collector its client secret#

The seeded Collector client's secret is on the client's page in Pulse (Clients, then Collector, then Reveal). Put it in the Collector's Pulse:Auth:ClientSecret, through the Collector's settings editor or as the environment variable Pulse__Auth__ClientSecret, and restart the Collector:

"Pulse": {
  "Host": "<your pulse address>",
  "Port": 4542,
  "UseTls": true,
  "Auth": {
    "Enabled": true,
    "ClientId": "Collector",
    "ClientSecret": "<secret from Pulse>"
  }
}

With that in place the Collector's interface sends people to Pulse to sign in, and the Collector can obtain tokens for itself.

The Authentication mode on a Historian link#

Each Historian the Collector writes to is listed on the Collector's Historians page, and in historians.config. The page shows each link's endpoint, status, the collectors that write through it and its authentication mode. The Authentication setting, on the link's own tab, says whose identity the Collector presents, by the same rule every link between two Timebase components follows:

In historians.config the mode is written as Host, Custom or Off:

"historians": {
  "hst_4f2a91": {
    "name": "Historian",
    "config": {
      "host": "<your historian address>",
      "port": 4512,
      "useTls": true,
      "auth": {
        "mode": "Host",
        "clientId": "",
        "clientSecret": "",
        "idP": { "host": "", "port": null, "useTls": true }
      }
    }
  }
}

A Custom client link names everything itself. Register a client in Pulse with the Historian among its audiences, as Registering Timebase apps as OAuth clients in Pulse describes, then set "mode": "Custom", the client id and secret, and the identity provider's host and port; the same fields appear on the tab once the mode is chosen.

The identity provider has no default host or port: a Custom link with either blank reads Connection Fault at once, naming what is missing. A Collector writing to several Historians can use a different mode on each link.

A link saved on an earlier Beta build with "enabled": true is converted on load, to Custom, or to Host when the client it named was the Collector's own.

What the link's status tells you#

Each Historian link reports its connection on the Collector's interface the way every plugin instance does: Running when it reaches the Historian and is accepted, Connecting… during a first attempt or an outage being waited out, Connection Fault when it cannot reach the Historian or was refused, with the reason naming the setting to look at. A Pulse that cannot be reached is an outage, retried quickly; a client Pulse refused is a refusal, retried slowly. A change to the link's settings is checked at once. See Plugin Instance States, Connection Status and Retries.

While the Historian or Pulse cannot be reached, the Collector keeps collecting and stores values to local disk; they are forwarded when the connection returns. See Store and Forward Operation.

Troubleshooting#