Migrating Data to Identity Panel

This article describes how to migrate identity data to Identity Panel from a legacy Identity and Access Management (IDAM) platform such as Microsoft Identity Manager (MIM) 2016.

• Authoritative data in Identity Panel
• Live-migration flow to Identity Panel - Design for MIM
• Live-migration configuration in Identity Panel
• Maintaining the Identity Silo post migration
• Delete and recreation of the new Identity Silo

Authoritative data in Identity Panel

In the context of an identity synchronization platform such as HyperSync or MIM, the term "authoritative" is used to describe the master source of both identities and their individual attributes. Whenever new authoritative entities are created, or their authoritative attributes updated, rules must be implemented to ensure scanned changes flow through the IDAM platform to all synchronized target systems. These rules also usually ensure that any scanned non-authoritative changes are subsequently overwritten on the next sync cycle.

When external systems are scanned for changes to a particular entity or set of entity attributes, such as en employee or department record in an HR system, flow rules are used to honour the authoritative nature of that source data. However, in some cases there is no external system to scan because it is internal to the legacy IDAM platform itself. In such cases, this creates a dilemma when migrating away from that legacy platform because a new authoritative source must be established to take its place.

A common scenario is where the MIM Portal has been used to master identity data such as the following:

• Group definitions, both static and query filter-based
• System accounts
• Foundation or Reference data such as department or cost centre

Post migration to Identity Panel, the expectation would be that any legacy IDAM platform such as MIM is fully decommissioned. Where identities are authoritative in that legacy platform, a new system is required for both initial migration and ongoing maintenance of this data.

Identity Panel provides such a replacement in the form of the following:

• An Identity Silo to be established as the new authoritative source,
• HyperSync Panel to "lift-and-shift" identity data to that new silo, and
• Service Panel for maintaining data in that silo post migration

As with any data application migration, a common Business Continuity challenge which occurs at the time of cut-over from the legacy platform to Identity Panel must be overcome. Specifically this involves balancing what are often conflicting objectives, namely:

• operating the legacy identity platform up to the point of cut-over to Identity Panel, and
• minimizing the outage time required during that cut-over while ensuring no loss of data integrity.

To overcome this challenge, Identity Panel supports a live migration approach whereby all data to be migrated is pre-loaded (scanned) into Identity Panel and constantly kept current by regularly scheduled data scanning.

Live-migration flow to Identity Panel - Design for MIM

The following describes the high level process of "live migration" of this data to Identity Panel in the context of a transition from MIM, where until now the MIM Portal has been used to maintain authoritative data such as groups.

In this scenario the data to be migrated exists in two repositories, namely the MIM Service/Portal and MIM Sync databases. Depending on the MIM design it may be necessary to access data in both databases, so for completeness both are depicted here.

In this configuration the live migration flows are as follows:

1. A dedicated MIM Panel Service performs an initial full scan of the MIM Portal (Service) database of all resources and required attributes
2. Subsequent delta scans are performed on a frequent cycle (e.g. hourly) to complement ongoing full scans (e.g. daily) are performed up to the point of cut-over
3. Service Panel writes scanned changes to the corresponding MIM Portal Identity Panel silo
4. The same dedicated MIM Panel Service performs an initial full scan of the MIM Sync database of all resources and required attributes. Ongoing full scans (e.g. twice-daily) are performed up to the point of cut-over
5. Service Panel writes scanned changes to the corresponding MIM Sync Identity Panel silo
6. HyperSync Stateful Sync rules are responsible for directly provisioning new IDAM Identity Silo (an arbitrary silo name to replace the MIM Service/Portal) with a minimal attribute set including a unique anchor attribute value
7. Attribute flows update the provisioned IDAM record with a complete set of attributes matching on the anchor attribute value
8. Projected Silo sync is responsible for updating the Projected silo with an aggregated attribute set for each migrated resource
9. With the above synchronization flows complete, the following interactions describe Service Desk (SD) User interactions up until the point of cut-over, starting with reading the latest MIM data via a MIM Portal search
10. The same SD user compares this to the migrated copy of the same by initiating a Service Panel identity search
11. The latest Projected Silo data is retrieved from Identity Panel and rendered as search results in Service Panel

Live-migration configuration in Identity Panel

The following describes the configuration steps involved in the set-up of a "live migration" design in Identity Panel, as described above in the context of MIM:

1. Align all data, binary code and configuration in all lower environments (DEV, QA, etc.) with PRODUCTION in the legacy identity platform
2. Implement One Design in all environments in advance of data migration, specifically including the following dependencies:
   1. Licenses for Identity Panel including each of Test Panel, Service Panel and HyperSync Panel applications
   2. Licensed data provider binaries to support connectivity to all managed external systems
   3. Data Provider configuration for all external system connections, including providers for the legacy identity data repository, such as MIM Sync and/or MIM Service databases
   4. Environment Variables to ensure consistency of provider configurations between all environments
   5. Panel Services in all environments to support scans from all legacy-managed external identity data repositories to corresponding data silos, including all legacy repositories to be replaced by Identity Panel
   6. Join Rules to unambiguously relate all identity records across all scanned silos such that joins are established and visible in the Identity Panel Time Traveler
   7. Maintenance Schedule configuration to perform all necessary operational activities to support operations, including index rebuilding, panel service restarts and upgrades, and join application
   8. Operational Schedule configuration to perform regular scans and Identity Panel synchronization of identity data in all environments across all externally sourced data silos
   9. Health Check Extension and Dashboard configuration to support the ongoing operations of each environment
   10. (Optional) Shutter Views to simplify the process of verifying resource matches between data sources
   11. Standard OneDesign reports including the HyperSync Actions report (e.g. for simulated sync rule assessment prior to turning off simulation mode)
3. Run all maintenance and operational schedules to ensure data silos are loaded and indexed for searching, resolving any operational issues that may be encountered
4. Identify the schema of a new identity silo to be domiciled internally to Identity Panel to replace the legacy store for all resources which must now be mastered in Identity Panel
5. Create a new Export Connections data provider and give it a name, e.g. "Actions"
6. Add an Additional System of type Identity Silo Provider for the Export Connections data provider and give it a name (e.g. "IDAM")
7. Instantiate identity records in the new Identity Silo for each resource type and associated attribute set in that schema using the Identity Panel toolset (e.g. using Test Panel or an Excel Actions provider)
8. Create additional join rules for each Identity Silo resource type to ensure migrated resources appear correctly in Time Traveler alongside their existing silos, including the legacy authoritative source
9. Create new Attribute Flow and Stateful Sync Ruleset configuration in HyperSync, and give them a name (e.g. "Migration - MIM to IDAM")
10. Within each ruleset create corresponding new Attribute Flow and Stateful Sync rules for each resource and associated attribute set from the legacy source silo to the new Identity Silo
    1. Apply rule expressions for any transformations required for when a direct flow rule is not appropriate, e.g.
       1. flows of reference and/or multi-value attributes
       2. boolean values will likely require the use of CoerceBool(MIM.attributeName)
    2. Where appropriate create new Custom Rule functions to simplify both understanding and maintenance of data migration logic, e.g. for complex rules or reuse in multiple flows
    3. When enough flow rules are in place, ensure both the attribute flow rule and parent ruleset is enabled
    4. (Optional) if necessary, turn simulation mode ON at the ruleset and/or rule level, depending on confidence level in the rule integrity and any risk of undesirable sync
11. Use Time Traveler to search for and locate identity instances for all resource types to be migrated
12. Use Identity Panel tooling (e.g. Time Traveler or Test Panel/Rule Tester) to execute the migration sync rules on individual or discrete sets of identities, and refine/correct rules as required
13. Run full synchronization schedules to execute all enabled migration sync rules/rulesets once verified, leveraging the simulation mode and HyperSync Actions report if required
14. Turn simulation mode OFF where set, and rerun full synchronization schedules as necessary to complete the data migration
15. Inspect all migrated data for completeness
16. Refine rules and repeat synchronization as required until full data migration is achieved
17. Deploy all fully tested new or modified Identity Panel configuration extending the OneDesign baseline configuration as necessary to support live migration to each higher environment

Maintaining the Identity Silo post migration

Once migrated, the most convenient means of performing create-read-update-delete (CRUD) maintenance on the new Identity Silo is the Service Panel application.

Since the migrated source data will no longer be updated, this is usually decommissioned at this point, involving the removal/deletion of migration sync rules and associated schedules, join rules and other configuration no longer required.

Subsequently, under version 7.* each resource type to be maintained will require the following Identity Panel configuration (at a minimum):

• A projected silo definition to support identity searches via the published Service Panel application, with hyperlinks to corresponding maintenance forms
• Forms for create/update/delete as appropriate, including workflows and actions for persisting changes in the target Identity Silo
• HyperSync flow rules to both synchronize Identity Silo data to target systems as required, as well as supporting and deriving references from HyperSync attribute flows for other identity types (e.g. a reference to an owned service account for an employee)

Such configuration is dependent on requirements that are unique to the legacy IDAM system replacement, and are therefore out-of-scope of any further discussion in this article.

Delete and recreation of the new Identity Silo

In some scenarios it may be necessary to delete and recreate Identity Silo. This may be to correct schema created in error, or to retest data migration in full from a clean baseline.

In this scenario, a special license can be installed and used with caution during a small operational window to allow purge and recreation of the new Identity Silo.