Feeling ‘Sun-burnt’ by your Sun Identity Migration Options? Part II

By Robert Block ·

In our last post, we discussed the various replacement options and pitfalls associated with Sun Identity Manager (idM) migrations. Clearly, we (FishNet Security experts) are recommending the “Regroup and Go” approach (Read part I).

Now that we’ve settled on this approach, there are some architecture options worth considering:

1. How will I maintain two systems in production?

This will lessen the R&R (Rip and Replace) pain if done properly — you move chunks (forgive the technical term) one at a time, depending on what makes the most sense for your business. Chunks could be:

  • Functions — birthright provisioning, then request-based provisioning, then others.
  • User Groups or Locations — perhaps you built it all in-parallel, then you migrate business units or departments in groups at a time from one solution to the other.
  • Applications — much like B above, you built in-parallel but now you migrate based on applications supported by Sun. This really only makes sense for organizations that have clean delineations between users who access these applications, such as internal apps, then B2B apps, then B2C apps, and so on.

2. What are the dependencies around what you build first in the new solution as you prepare the parallel deployment?

  • Can Sun Identity Manager be leveraged as a source of data or, even better, a part of the overall migration? (More on this in a moment.)
  • If so, now you must focus on the following (in order of complexity):

     i. Data Sources

     ii. Data Mapping

     iii. Business Processes

     iv. Connectors

     v. User Interfaces and Workflows

If you’ve noticed, I have twice mentioned referenced information to be provided later in this post. The first was in the connector conversation above, and then again when I referred to Sun IdM as a source of data or as part of the deployment. So, to now expand on those points, there are two things that you must consider here:

  1. If Sun is the authoritative source for data and processes (from vendors, contractors, contingent workers, etc.), guess what? It isn’t going anywhere until you replace it with another authoritative source.
  2. While I have avoided mentioning alternative technology vendors in this blog, I am going to give a small yet warranted shout-out now to SailPoint. From the technology’s inception, SailPoint has attempted to be vendor-agnostic in its approach to provisioning. So much so that it has created PIM (Provisioning Integration Modules) that deploy from the SailPoint provisioning broker directly onto third-party Identity Management products. The current Sun IdM PIM connects Sailpoint Identity IQ directly to Sun Identity Manager’s identity engine to leverage the currently built connectors —as opposed to building new ones.

Based on over 15 years of InfoSec and IAM experience, I believe this approach is profound. Choosing SailPoint IdentityIQ (IIQ) allows a client to first connect to Sun IdM from SailPoint, then use Sun IdM as a source of data and supporting infrastructure. Now we can focus on building a sustainable role model in Sailpoint IIQ, build out interfaces and workflows in IIQ, put IIQ in production, and then, over time, rip and replace one connector at a time until all connectors are pulled from Sun Identity Manager.

WOW — great idea, but with one significant catch: In order to build a valid and detailed role model, you must have accurate information as to the current access rights a person has within a given application. If active reconciliation is not configured, then Sun IM never knows when access is changed in the target system. As a result the role and access information will be outdated.

While I wish I had some magic powder, some special dust or mystical spell to make this Sun migration painless, but absent of this kind of magic, choosing an experienced vendor with the strong technical depth and credibility will provide you with the appropriate “Sun-screen” to prevent you from getting “Sun-burned.”