Identity Architectures (version 24)

When installing the Canary system, it is important to determine where the Identity service will be located as other Canary services must connect to it when authenticating and authorizing users. At least one Identity service is needed per system, but more can be added if multiple networks exist within the system architecture.

Single Historian System

In a single Historian system, only one Identity service is needed. Remote Canary Collector servers do not require a local Identity service. They will be pointed to the remote Identity service during the installation process.

Multi-Historian System

If a system contains multiple Historians within the same network, still only one Identity service is needed; however, this does create a single point of failure. The benefit is that there is only one location to configure users/groups/API tokens for the entire system. The remote Historian servers will be pointed to the remote Identity service during the installation process along with any Canary Collector servers.

If each Historian system were to use its own Identity service, configuration changes would have to be made for each one, requiring more manual intervention. A redundant Identity architecture may be the best alternative in that case.

Multi-Tiered Network

In a multi-tiered network, an Identity service is needed at each level where users must authenticate to consume data. Assuming that Level 3 cannot communicate with Level 4, an Identity service is needed for each.

Redundancy

If needing to achieve a redundant environment, the Identity services will need to be placed behind a load balancer. Each Identity service will then need to be configured to store its information in a MSSQL server. The Identity services can be installed on their own separate servers or reside on the same machines as the Historians. Both architectures are supported.