Problem

A Forum reader recently asked:

"How would I upgrade individual driver configurations to the new architecture outlined in section 2 of "Understanding Policies for Identity Manager 3.5.1"? We have done some driver customization in various policies, but we used the existing default names.

If we overlay the policy configuration files to exploit the new architecture, is that where the potential risk arises?"

And here is the response from Aaron Burgemeister ...

Solution

Regarding the transition from IDM 3.0.x to 3.5.x ...

3.0.x uses linkages between policies (linked list-ish). 3.5.x uses a multi-valued attribute on the driver itself, which points to all of the policies. The IDM 3.5.x engine will work with the 3.0.x style; each time you go into the driver it alerts you that you should convert.

The "risk" is negligible (I've really never seen this break myself during the conversion) because the policies themselves are not really touched. Only the linkages to the policies are modified, which doesn't involve
looking at your rule names or logic.

Here's a rough overview of how it works:

Driver30x
~ Output Transform Stuff -> OutTransPolicy0 -> OutTransPolicy1
~ Creation Stuff -> MatchPolicy0 -> MatchPolicy1
~ Matching Stuff -> MatchPolicy0 -> MatchPolicy1

Driver35x
~ Output Transform Stuff
~ OutTransPolicy0
~ OutTransPolicy1
~ Creation Stuff
~ CreatePolicy0
~ CreatePolicy1
~ Matching Stuff
~ MatchPolicy0
~ MatchPolicy1

The contents in the policies and their respective rules don't matter - only how the driver points to the policies is changed. Just have an export beforehand and you'll be fine. This is really simple to convert, so there haven't been any issues that I know of.