Identity Panel Architecture Overview

This document provides a high level overview of the Architecture of Identity Panel, with updates for the Version 7 release, and links to existing documentation on key components.

Identity Panel Application Suite

Identity Panel is a suite of the following applications:

• Identity Panel
• Service Panel
• Access Panel
• HyperSync Panel
• Test Panel

Version 7 introduces:

• A consolidated user interface for Access Panel in Service Panel
• Optimization to natively perform near-real-time calculation for just-in-time access entitlements in response to the latest identity changes in both provider-scanned system context as well as the passage of time (temporal) context.

Identity Panel Application

The Identity Panel application consists of several components:

• App Service - where the application runs and queues workflow actions
• MongoDB - where data is stored
• Elasticsearch/Atlas Search - where indexing is performed for on prem/hosted installations
• Azure Front Door WAF - how access is controlled and additional layers of security provided (SaaS only)
• Panel Service - where the workflow queue is processed, whether installed on-prem or run as a hosted service

Identity Panel Interactions with External Systems

When configuring Identity Panel, you setup Providers.  Providers are Identity Panel's means of read connectivity to the external data sources it needs to scan. They are also the conduit for create, update and delete actions against the same data where this is both required and supported by that system.

The following are key characteristics of Provider interactions.

• Providers typically invoke methods published in system APIs (SCIM, REST, SOAP, ECMA2, etc.), but can also be written to access underlying databases (SQL), data files (CSV, EXCEL, JSON, XML, etc.) or a dataset constructed via script (PowerShell).
• Once a provider is created, the actions for execution against that provider must be configured.  In Identity Panel, this could be a Schedule Task to create an action to read the data, or in HyperSync an action workflow to create an object.
• Multiple instances of Panel Service can be configured, and every two minutes, Panel Service will connect to Identity Panel, and see if there is any actions in the workflow queue that need to be processed. This connection will use port 443 over HTTPS to ensure the network traffic is encrypted.
• When Panel Service connects to applications, the ports, rights and permissions used will vary from application to application.  Importantly, connections are always initiated from a Panel Service to the Identity Panel application and never in the reverse.  All messages sent from the Identity Panel application are only ever in response to a Panel Service request.
• Panel Service will
  • pick up an action from the workflow queue,
  • execute the action, and
  • send a message back to identity panel on completion.
• When Panel Service scans data into a Silo for a given provider. that data becomes immediately available for viewing in Time Traveler.  Furthermore, if automatic (delta) synchronization is enabled for HyperSync, immediate additional sync actions may then be performed in response to those changes in the data.

The diagram below shows a high-level overview of a typical Identity Panel implementation, together with several on-prem and SaaS application Provider integrations.

More information on Panel Service Architecture can be found here