MIM Design Principles when migrating to HyperSync

Nothing database-specific to the MIM application translates to HyperSync.

There are only 2 topics of minor relevance at an abstract level:

1.  Memory utilization if running in an on-premises or VM host.
   1. Refer to MongoDB best practices for a generic approach to IdP deployment on prem.
2. Backup and recovery
   1. As with any approach to DR planning, a MongoDB database backup strategy is fundamental.
   2. Refer to MongoDB best practices for a generic approach to database backup and recovery.

This is to mitigate a risk in MIM that only applies to MIM Portal deployments, which is only relevant to MIM Sync when declarative rules are in place.

For HyperSync Admin access:

• Admin access to the IdP application is governed by the configured Security Role mappings.
• Membership of the mapped security principal (e.g. AD or Entra group) is fully managed externally to the application

This is to mitigate a security risk in MIM that only applies to MIM Portal deployments, which is only relevant to MIM Sync when declarative rules are in place.

However, if deploying IdP on premises with an Exchange mailbox, the same guidance may also apply when configuring IdP email sender(s).

This is to mitigate resource exhaustion for MIM that only applies to MIM Portal deployments, which is only relevant to MIM Sync when declarative rules are in place.

There is no equivalent consideration for HpS/IdP.

As with MIM the Initial Load of IdP/HpS requires careful planning.  There are some specific parallels, but reference should be made to the main HpS Design guidance covered in the M900 Training Syllabus.

The following are specific references to this MIM section:

• Step 2: A minimal set of rules should be enabled initially (typically disabling all outbound attribute flows and stateful sync during initial load).
• Step 3: Synchronization and export sequences are a variation on the per-connected-system approach described
  • Note that setting a global Simulation Mode flag in HpS is a recommended approach for previewing synchronization over either a full or scoped user base.
• Step 4: Applying the full MIM configuration is analogous to enabling all sync rules/rule sets and turning off global Simulation Mode (if set)

Note: For a complete approach to an initial load where data migration from a legacy IDAM platform (including MIM) is required, refer to Migrating Data to Identity Panel.

This is to mitigate a risk of failed MIM schema and policy deployments for MIM Portal deployments, which is only relevant to MIM Sync when declarative rules are in place.

Like MIM (xml files), there are config files (JSON) which are downloaded/uploaded to IdP in a pre-determined sequence as part of any migration.  As with MIM migration:

• Avoid changing display names unless you make the same changes in all environments prior to migration (to ensure name matches where relevant)
• Avoid changing the content of intermediate (JSON) files as part of the deployment - unless practiced

However, the configuration migration for IdP/HpS is subject to its own guidance which is discussed separately in the M900 Training Syllabus.

The following MIM items have relevance to the corresponding IdP components

• The Panel Service account is subject to similar guidance as the FIM Synchronization Service and FIM Services accounts
  • This also applies to the IdP application service account for on-premises deployments
• Implementing SSL guidance for IdP is discussed as part of Hosted Architecture – SoftwareIDM

• End-user permissions should use explicit attribute lists scoped to users business needs - achieved through IdP Audience rules