Introducing Stitcher - OAM Configuration Migration Solution

Many of our readers are aware that we have had the "COREid Migration Service" available for public use for the past three years. This service has been a resounding success with several high profile North American OAM customers relying on it to maintain consistency across their environments. The expression, "If it ain't broke, don't fix it." best describes our attitude towards the initial release.

But the time was right for a platform upgrade, some rebranding, and some minor issue fixes.

Stitcher lives at the same address as the original service. If it sounds like something you've been missing, check it out.

Policy Domain/Policy Not Enforced

Successful migrations of Oracle Access Manager (formerly COREid) configuration data rely heavily on consistent directory naming of entries between envionments. It is not enough for configuration data objects to share the same user friendly names, they must have the same RDN (Relative Distinguished Name) values in the directory server. This forms the basis of clean migrations. As well, objects must share the same properties. If this setup is performed in advance of using the COREid Migration Service or alternatively, corrected in a pre-existing environment using the COREid Migration Service migrations will run smoothly. The situation described below illustrates how having inconsistent environments can cause problems.

After copying a policy domain or policy to a new environment the resources protected by the policy domain and/or policy are not actually protected there. Checking the resources in the Oracle Access Manager Access Tester reveals that the resources are indeed not protected.

This error highlights a mismatch in host identifier data between the source and target environments. It may look the same (i.e. have the same user friendly description in the UI), however, the distinguished name (DN) that names the object in the directory is probably different.

The short term solution is to add the host identifier for that environment in all of the locations in the policy domain(s) and/or policy(ies) where resources are specified. This will get the policy domain(s) and or policy(ies) working again in the target environment. However, there is still a longer term problem that will affect future migrations of policy domain data.

This long term solution is to use the COREid Migration Service to migrate host identifiers and policy domains from a stable environment (production) to all of the other evironments (i.e. quality, test and dev) and systematically update the host identifier entries with host names specific to the environment. This will make the other environments consistent a prevent this problem from occurring in the future.

COREid Migration Service

Although we are continuing our invitation only pre-beta phase, all are welcome to peruse the information now publicly available.

https://extranet.nulli.com/migration/

COREid Migration Service Preview

For the folks that have been wanting a closer look at the migration service here is a quick run down with screen shots.

This should give you a pretty good idea what this is looks like.

The Nulli Professional Services team is using this in the the field today and our pre-beta invitees are taking their first steps on their own.





Thanks for your interest so far.

COREid Migration Service Enters Pre-Beta Phase

Nulli Secundus is pleased to announce that our COREid Migration Service has entered a pre-beta (invitation only) phase. We are currently inviting a small group of Nulli customers to begin to use the tool.

The COREid Migration Service is a Nulli hosted web application to which users may upload COREid configuration data in LDIF format. The service processes the data from the source and target environments and returns a single LDIF file suitable for import into the target system. The goal of the Migration Service is to support COREid administrators in duplicating COREid Identity and Access application behavior across separate COREid installations.

The COREid Migration Service will be available at no cost to registered users.

If you would like to be notified upon general release of the service or if you would like to be considered for the pre-beta invitee pool, please send an email stating your interest to mark at nulli dot com.

Horizontal Migration of COREid Configuration Data

The professional services consultants at Nulli Secundus live and breathe COREid on a day to day basis. And we do so in a wide variety of customer environments. It goes without saying that we are always learning and improving the patterns we employ to achieve success with Oracle COREid Identity and Access.

One common customer question that comes up with every engagement is, "How do we move this stuff?". Meaning- "We're following best practices by staging our environments but we don't see a good way to move development to quality assurance, and quality assurance to load testing and on to production...".

Pam Dingle started working on this problem at Nulli Secundus some time ago. Janelle Jowsey took me under her wing as she turned Pam's invention into a software product that worked magic on COREid configuration across staged tiers. The result of all this thought and effort is the fact that there is literally nothing we do not know about the inner workings of the COREid configuration data.

At this point in our history with COREid we know exactly how it should be deployed and staged, and we have the knowledge and tools to efficiently migrate COREid configuration data across enviroments. We can demonstrate perfection in the movement of any Identity or Access application configuration data and we can do so measured in a scale of minutes.

We're in the process of formalizing the ways that we can share our knowledge and tools most effectively with the COREid customer population. Watch for more information on our web site coming in the second quarter of 2006.

If you're really keen to put an effective system around this challenge in your environment and you want a hand in shaping some of the stuff we're working on, please get in touch with us. We'd be pleased to talk with you and would welcome your input.

Disappearing Workflows During Horizontal Migration

If you work safely within the confines of the COREid Identity admin ui then you are protected by a friendly message that pops up when you add an objectclass to a tab. The message tells you that the operation will fail if you have any pending workflow tickets.

What happens behind the scenes as you add the new objectclass to the tab is that the system also adds the same objectclass to all the workflow definitions associated with that tab.

The take away here is that if you are manually migrating tab definitions from one environment into another you will break workflow definitions in the target environment if there is an objectclass difference contained in the new tab data. When this situation arises the rule is that the tab and all the workflow definitions for that tab must move as a unit.