Identity Panel Managed Service Console technical description

Applies to version: 3.3.4 through 4.1 of Identity Panel and the version 3.3.4 through 3.3.8 of the Identity Panel Managed Service Console.

Introduction

There are two components to the managed service console.

1. Service Feed for Identity Panel Enterprise Edition
2. Service Admin role for Identity Panel Azure Marketplace Edition

Service Feed for Identity Panel Enterprise Edition

The service feed is configured in the providers section of the on-premise settings. Before creating it the user must go through the regular Identity Panel Azure Marketplace Edition signup process and license claim process with the Identity Panel Azure Marketplace Edition instance of choice. This may seem odd, since the customer is hosting Identity Panel internally; however, an Identity Panel Azure Marketplace Edition tenant must be created to enable the Identity Panel Core Framework to collect information needed by the managed service provider. The user will then configure the service feed provider with the same settings that would be applied in a Panel Tools installation.

After setting up the feed, the user must perform an OpenID Connect authentication against the SaaS instance to create a pre-shared Panel Tools login, except this must be done for the SoftwareIDM Maintenance service executable.

Finally the user indicates what types of data to forward to the cloud service.

Once the data is in the cloud, the managed service console functions in all other respects like a regular SaaS customer.

Managed Service Console

All Identity Panel Azure Marketplace Edition customers have their own database identified by their tenant Id, and an entry in a shared database which contains:

• The DNS name of their Azure tenant
• The issuing tenant Id
• Database connection information
• API Key information
• Service Admin (optional)

The tenant tracking record has an optional setting for Service admin, which may only be set by SoftwareIDM, and must be the GUID identifier of a group in Azure AD.

The service admin id allows users in one tenant to impersonate access in another tenant with a special case role of service admin.

If a request to Identity Panel specifies the X-Tenant-Override header with a Tenant ID, Identity Panel checks if the targeted tenant specifies a service admin group, and if the user’s Azure OpenIDConnect groups claim contains the specified group. If so, IdentityPanel redirects the request against the targeted tenant database. The request will appear in the access log for the targeted tenant with the foreign tenant’s Azure identifier.

To summarize, accessing another tenant requires the following:

1. The targeted tenant must specify a Service Admin group Id. This must be configured in advance by SoftwareIDM.
2. The group ID must exist in the user’s own Azure AD directory
3. The user must be in the specified group as identified by their Azure OpenIDConnect claim token
4. The HTTP request must specify the GUID of the targeted tenant in the X-Tenant-Override header.

To make this process simpler for service providers, if a user is a service admin in one or more foreign tenants, Identity Panel provides a Service Admin drop-down at the top of each settings page, which the user may use to toggle their browser session between tenants. The tenant targeting is not remembered and will be reset by a page refresh.

When accessing another tenant all pages have a yellow bar across the top indicating the active tenant.

If an organization manages other tenants, it is possible to create dashboards where individual modules have their own tenant override settings.

By default, service admins have very limited access to data in the foreign tenant. They are restricted to operational object types and may not view Identity object types. Service admins have read only access to:

Health Check Results

Panel Tools log output

Run history information (includes error data, but not related identities)

Schedule execution state

Workflow instance state

General settings (but not password decryption)

Report definitions (but not generation)

Starting with the 3.3.4 release it will be possible for Identity Panel admins to select Service Admin as a built-in security principal when creating custom security roles. This will allow per-tenant customized elevation of service admin rights to e.g. view identity data, generate reports, or managed schedules.