by Xiaofang Chen on April 14th, 2012

I see an Oracle Waveset Identity Manager (previously Sun Identity Manager) Migration project as a cooking challenge where you need to recreate a given dish in a particular time frame. You are going to be using different tools and techniques in your reconstruction but it has to resemble the taste and look-and-feel of the original dish. I could guarantee that almost everyone knows how to approach the challenge. First you carefully observe the original dish by tasting and feeling its texture, then identify the individual ingredients, and finally design a recipe by choosing the right tools and applying appropriate techniques. Your satisfaction with tasting the final product might vary but we are able to have the approach nailed down. I wish choosing the right IdM Migration approach could be as simple!

Let me explain what I mean. Some companies we know view the Migration effort of their Sun IdM solution as another infrastructure application upgrade. Their approach is driven by the Migration Toolkit released by the vendor (Oracle). We call this approach “Migration by Objects” since the list of various resources / components / assets inside the Sun tool is generated by the Vendor Migration Toolkit, then analyzed and migrated. The problem of this bottom-up approach is similar to the problem of recreating  the original dish by starting with the list of ingredients. The overall taste and feel (i.e. business requirements) might be lost during such "translation". Consider the following situations:
  • There are duplicate solutions implemented in the existing Sun IdM implementation (e.g. manual vs. scheduled) due to historical reasons. Only one of them needs to be migrated
  • There are existing objects (e.g. workflows, reports) that are never referenced/used in current system
  • There are obvious improvement opportunities in certain areas of business processes
  • There is existing customization that could be easily replaced by the latest advancement in Identity Management (e.g. customized java classes vs. Out-Of-Box Password Synchronization Adapter)
The opposite of “Migration by Objects” approach is to focus on re-designing the new system based on business requirements and processes. We call this approach “Migration by Use Cases”. The potential risk of this approach is overlooking functionality details and not fully leveraging the existing implementation. This is similar as to recreating the original dish without analyzing the detailed ingredients. Imagine realizing the end product is missing some key ingredients after the solution is delivered.

What we need is a well-balanced hybrid Top-Down (“Migration by Use Cases”) and Bottom-Up (“Migration by Objects”) approach. Overlooking one or the other introduces risks to the success of Migration. Unfortunately, most of Sun IdM Migration tools in the market nowadays are designed to facilitate the Bottom-Up (“Migration by Objects”) approach. They could be used to generate a catalog of existing Identity Objects and even to auto-migrate some simple objects (e.g. users, security objects) onto a particular Identity Management platform. But they fail to provide information from the perspectives of business processes/use cases.

Thus we, Identigral, have created our own Sun IdM Migration Toolkit to facilitate a hybrid Top-Down (“Migration by Use Cases”) and Bottom-Up (“Migration by Objects”) approach. This Toolkit could be used to auto-discover use cases by analyzing the implementation objects (e.g. Java class, XML objects) in an Identity Management solution repository. It fills the gap missing in other IdM Migration tools by establishing the connection between the business view and the underlying implementation. We have started applying this Toolkit in our current Sun IdM Migration projects and have received positive feedback from clients after seeing how much value it brings. Feel free to contact us if you want to learn more about the Toolkit. And stay tuned -- this toolkit will soon be available for OIM 10g Migration projects as well.

by Xiaofang Chen on June 20th, 2011

Doraemon - you’ve seen him even if you don’t know his name, the cutest robotic cat from the future! He was my favorite cartoon character when growing up and he's going to help us today.

When attempting to visualize this (magic) migration tool from Oracle Waveset/Sun Identity Manager to Oracle Identity Manager 11g, (see previous blog entry "Grown Kittens Need a New Home"), I can’t help but to think of Doraemon. He has a 4-dimensional pocket from which he produces gadgets and tools from the future. The Take-copter (a propeller which can be attached to anything to enable flight) is my all-time favorite. So what will come out of Doraemon’s pocket if his next mission is to migrate a solution based on Waveset/Sun Identity Manager to Oracle Identity Manager?
Recently I had a chance to take a closer look at the to-be-released Sun Identity Manager/Oracle Waveset (SIM/OW) to Oracle Identity Manager (OIM) migration toolkit. Here are highlights of what I have learned.

1. OW objects that can be directly mapped to their equivalents in OIM. These will be automatically or partially migrated
Not too many surprises here. A good portion of OW objects could find direct mappings in OIM:
- Enterprise Identity Data Objects (e.g. Organization, Role, User, and Resource)
- Schema Templates and Policy Objects (e.g. IDM Schema Configuration, Email Templates, and Password Policy)
- Administration and Authorization Objects (e.g. Capabilities and Admin Roles)
- Business Logic and Process Data Objects (e.g. Process/Object Forms)

But not all features of these objects could be directly mapped to OIM. For example, dynamic variables in OW Email Templates need to be manually configured in OIM once these templates are automatically migrated. How much these OW features are used in your OW/SIM implementation will determine the amount of automatic translation that could happen.

2. OW objects with no direct equivalent in OIM. There will be a report capturing these objects and they will require manual migration
Again, this is what we expected. As a general rule of thumb, any customized XPRESS scripting will likely require re-implementation. The migration toolkit will not be able to translate XPRESS logic into SOA composites or OIM adapters or Java code underlying adapters. User Interfaces and Workflows fall into this category.

3. Audit trail / historical data. These records will not be automatically migrated
As OW and OIM employ different schema for persistence of audit records, Oracle advises customers to follow a co-existence strategy. In this approach, audit artifacts would be generated from either OW, OIM or both depending on context / need.

4. Identity Connector framework will be leveraged by the migration toolkit
Oracle plans to build both OW and OIM resource connectors on top of the new Identity Connector Framework (ICF). It’s already available to OW customers as long as they upgrade their installation to 8.1.x. This not only enables them to leverage new features and enjoy updates to the connectors provided by Oracle but also unifies the underlying infrastructure for a seamless transition by the migration toolkit.
Overall, the OW to OIM migration toolkit by Oracle is a respectable attempt at automating the migration tasks. It pays attention to details regarding product differences and focuses on identifying customizations that require manual effort to migrate. For example, the toolkit takes care of passwords and challenge questions/answers when migrating OW users such that end users won’t need to reset passwords or re-enter their challenge answers in OIM.

On the other hand, no magic tool could solve real life problems in a quick and easy way. (This was one of the lessons taught in Doraemon’s stories). Take “User Termination” use case from our previous example. The pre-migration analysis produced by the toolkit (third column in the table below) needs to be reviewed by subject-matter experts who understand both the product and the business process the product implements so as to come up with an accurate estimate of the migration effort (fourth column in below table).

And that’s how we, Identigral, are able to help. Our team combines leading expertise in various Identity Management products (especially Sun Identity Manager/Oracle Waveset and OIM) with a proven track-record for successfully delivering and migrating Identity Management solutions. Feel free to contact us if you're interested in having Identigral help you by bringing proven methodology, best-of-breed migration tools and extensive knowledge base.

by Xiaofang Chen on May 31st, 2011

When Oracle announced that “Oracle Identity Manager will be the strategic Identity Administration and Provisioning product moving forward" and with Oracle Waveset going into ‘sustain and converge’ mode, I was ready to offer all of my Waveset knowledge for adoption. Having delivered Sun Identity Manager projects all the way from when it was “Waveset Lighthouse” (Sun acquired Waveset in 2003), I am personally attached to everything I engineered on top of Waveset throughout the years. For the time I spent getting to know my Waveset customers, taking care of their needs and trying to build/customize the best home possible for the growth of their business, it’s difficult to see them become homeless. But as a person who believes in change (or sifting a sieve full of unsifted thistles), I am optimistic that it will be a change for the better and a better home is out there. Maybe.

While not all Waveset customers face the challenge of migrating their solution to a completely new platform, quite a few will consider this option. Migration is a far more complicated task than simply porting software to a different platform or deploying applications in a new runtime environment/container. Imagine migrating a very common “User Termination” use case from Oracle Waveset to Oracle Identity Manager. A typical scenario goes like this:

1) a user’s record is updated with a future termination date in company’s HR system (the authoritative source),
2) IdM system detects the update and tags the user for termination on that day,
3) when the termination day comes, IdM system automatically de-provisions user’s access in connected resources and emails appropriate parties to manually remove user’s access in non-managed resources. A simplified version of Oracle Waveset implementation might look like this.
Few objects such as Connectors could be mapped directly from Waveset into Oracle Identity Manager as the same concepts exist in both platforms. Email Templates and Task Scheduler could be migrated with minimum effort. But the majority of objects with heavy dose of business logic require significant effort to re-develop in Oracle Identity Manager. They could potentially be replaced by out-of-box and customized Process Forms, Adapters and Provisioning Processes with features split or merged from different Oracle Waveset objects. Sounds quite sticky and rightly so. In my opinion having automated tools do this re-engineering for you is certainly possible but it would be very difficult to achieve with reasonable precision and accuracy. These "translations" are really a case-by-case battle, not to mention having to ensure performance and scalability in newly generated code. Y2K tools and vendors should enter this market!

The success of migration is not determined by being able to map every single Oracle Waveset object onto its Oracle Identity Manager equivalent but rather by having the business process successfully implemented on the target platform. The termination example is a relatively simple use case. For example, if you have scenarios involving approval workflows (and most customers do have them), they add a few more layers of complexity to the picture.

Besides the migration effort itself, there are also other challenges that Oracle Waveset customers need to keep in mind when moving to a new platform:

1. A smooth operational transition
The migration effort calls for both implementation of a new solution and the operational transition. Customers of Oracle Waveset need to ensure a smooth transition while at the same time continuing to support the existing solution and even investing further to meet evolving business needs. Tall order.

2. Consider migration with improvements
Companies often choose to leverage the migration opportunity to find ways of adding new features and improving existing implementations. Some say they do this in order to streamline business processes, reduce operational costs and improve performance. Others say they do this to justify the budget. The truth is in between (and out there). Improving life while moving to a new platform is even a taller order.

3. Select the right implementation partner
Due to the nature of work and above challenges, migration projects call for professional business planning and execution, subject matter expertise and deep product knowledge. To have a well-designed plan and resources from the right implementation partner with both old and new product knowledge is the key to success. (Our supercomputers borrowed from the National Security Agency) tell us that you, dear reader, might be interested in hiring us to hep you with migration. Kittens are optional).

There is no rush to take on the migration, but it’s never too early to start planning. Now is the time to know your options. It's also interesting to widen the scope of inquiry a bit and take a look at the latest advancements in Identity Management marketplace. To help you get started, we will review some of the available migration tools and discuss best practices of pre-migration preparation. Stay tuned.

by Deborah Volk on June 3rd, 2010

If your refridgerator needs to be cleaned out, everyone living with you probably knows it because the task is usually so far down on your to-do list, you might as well plan a trip to Mars first. The task moves up the list as the odor becomes worse with each door swing. Eventually it reaches crescendo when your friends, neighbors and significant other(s) can stand it no more. This is the point where the "smell" becomes the "stink" or for those of you counting yourselves as fans of Sir David Attenborough, it becomes titan arum.
Back in the 1990s, Kent Beck coined the term "code smell" to refer to symptoms in code that could point to a deeper underlying problem. Typically these symptoms don't break the code and they work, but over time the "smell" can become a "stink". Since Kent, developers have been documenting "code smells" for different languages, contexts, and methodologies. And like any smell, what is perfume to one is blue cheese to another.
Recently I've been thinking about smells in a typical Oracle Identity Manager implementation. As is true for any enterprise-grade software deployed to solve real-world problems (read: abused and exploited) there are patterns that work well and some that don't work so well.

Detecting Blue Cheese in your Oracle Identity Manager deployment:

- Encyclopedia-like User Profile (Xellerate User / USR). I've seen user profiles with as many as 50 attributes. Although this varies with context, I think 10-15 attributes is a reasonable max. If Xellerate User entity represents your "core" identity, you should not have attributes on it that are better placed with the resource/target. Regarding access policies that fire based on groups which are driven by rules that work only on Xellerate User fields, here's a hint: rules are not the only way to become a member of the group.

- Duplication of Adapters aka Copy and Paste Programming. The raison d'etre of adapter mechanism is reuse. If you spend time designing your adapters and (shock! horror!) thinking about a library of adapters just like there are class libraries and frameworks made up of class libraries in various class-friendly languages, you won't see 10 copies of AddThisStringToThatString.

- Large Adapters. Don't click yourself to death and force others to drill down on two pages worth of visual spaghetti that ends up being generated code anyway. If it's more than a screenful (and I don't mean you over there with a 52" screen), it's too much and should be refactored into smaller adapters and/or underlying code.

- Tiny Lookups. Lookups with a few records at the most, sometimes (adding insult to injury) with code (attribute) and decode (value) being the same.

- Bloated Lookups. Perhaps the most frequently encountered smell after Duplicate Adapters and JARs Everywhere. This is when a lookup contains more than 10-15 records, occasionally running into hundreds of lines. OIM can be somewhat blamed for this as there's no good alternative for persisting app-specific metadata in the database unless you want to do it in your own (separate from OIM) tables using your own method.

- Environment-Specific Data Outside of IT Resource. Environment-related data is often spotted as task attributes. In other words, the same logical data element (e.g. server hostname) is present in a number of places. Moving OIM to another environment makes this smell a lot of fun!

- JARs Everywhere. Same JAR in JavaTasks, ScheduleTask, <oim_home>/lib, app server classpath, and (for a truly good measure) a few different directories inside the JDK. Classloaders of the world, unite! You have nothing to lose but your already loaded classes.

All of the things above would work, but over time, these things will start to turn your Provisioning Perfume into something a bit more pungent.

What is your favorite (or dis-favorite) OIM smell?

by Deborah Volk on April 28th, 2010

I hear that the Age of Facebook is upon us. While I was busy tending to my identity and access tomatoes, the new dawn has been declared. Apparently right outside my window there be walking people whose identity has been sucked into a space-time deviation yet they're blissfully unaware of this. For those of you in the know (read: in the possession of a secret handshake), the Age of Aquarius is really where things have been happening for a while but I digress.

Astrology and social networking aside (wait, aren't they one and the same?) I think we're in the Age of Fast, Faster and Oops-Reboot-Button-Really-Works. The immediacy of content and the ease of access leads to different expectations versus those that existed merely 5-10 years ago. We want our movies streamed on demand with no network lag, our books in some digital iFormat, our identities to be portable yet private, our chicken wings to taste like 5-star French restuarant fare..

Who's to blame for this massive shift of the entitlement scale? I would like to blame the aliens but those folks at SETI are awuflly slow so I will blame Google. To be more exact, I will blame it on their unwavering belief that a simple search box can yield the answers to just about anything. Once they had consumers convinced, they started replicating the idea everywhere. Notably in GMail one can find emails by combining a few simple and easy to remember operators. For example, to find all messages sent to you from anyone at with an attachment, you could enter from:* has:attachment into the search field and voila, you're showered with text.

Now transport yourself back to the land of identity management. A typical IAM application is a bunch of tomatoes on top of a large database (LDAP is only a protocol, don't fool yourself). The content in the repository has a lot of value but only when it's appropriately harvested, extracted and made available in a cupcake format. If there ever was an enterprise application ripe for a pervasive search-as-an-interface-to-everything disruption, IAM is it.

Have you ever had to run a report in your identity or access management tool? Say, give me all users who have been provisioned to Active Directory in the last week. Given a reporting requirement of any sizeable complexity the implementation task would end up being either a nasty SQL query directly to the database or a mini-marathon with a reporting solution.

Enter Scroogle (pronounced SCROO-gul), a kinder, gentler and an entirely textual solution to the reporting problem. Scroogle is a search engine that would be embedded into an identity or access management product. Instead of fiddling with reporting knobs or trying to decide between left and right outer join (both are charities for circus acrobats if you ask me), one would use a very compact domain-specific language a la GMail operators to get results. For example, the Active Directory report above might look like has:AD status:Provisioned when:last week. Right now Scroogle is a figment of my imagination but I am sure IAM product vendors reading this blog will take notice and "borrow" my idea. All I ask in exchange is a six-figure royalty check paid in gold bullion.

P.S. Scroogle is actually a very real and useful ad-free Google proxy service

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)