Anonymous_User Absent Member.
Absent Member.
169 views

Fooling the merge process.

OK,

Here's the scenario.

Objects of a type (group) are syncing between IDM and connected system
(in both directions)

Depending on an identifying factor (CN prefix, OU placement, mapping
table etc) for some of these objects I want to use the filter to
implement different logic.

For example

Objects in category A - simply sync group membership from connected
system to IDV

Objects in category B - reset any group membership changes from
connected system and sync changes from IDV.

There are several of these attributes that differ in behaviour (and not
all are "reset")


I thought I could get smart and use some custom schema mapping to
convert objects from category B to a "virtual/aux object class" that
had the same attributes configured but different filter values. The
object class used is a valid aux class and set on the object in
question.

Via schema mapping, I sucessfully change the object class on an event
from the connected system to my "virtual/aux object class"

However, the merge process sees through my trickery. Somehow it
realises this object is primarily a group in the IDV and reverts to
using the group attributes specified in the driver filter to perform
the merge.

I really don't want to code specific logic (for example reset) for all
the attributes that fit in category B. That way means a lot of testing
and special case logic.

Another option is to sync these objects via a second driver - but as
they include group membership that means I need to also sync user
objects from both drivers - which is far from an ideal solution.

Anyone got any ideas or do I have to go with the "code exceptions for
each attribute" approach?

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
Labels (1)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Fooling the merge process.

> Another option is to sync these objects via a second driver - but as
> they include group membership that means I need to also sync user
> objects from both drivers - which is far from an ideal solution.


Unless you convert the type of attribute to a string (from a DN) before it
is stripped off due to lack of association. The engine doesn't seem to
mind this and I've done it before, and seen others do the same, for
example with nspmPasswordPolicyDN when a driver is synchronizing those
links between trees.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Fooling the merge process.

Alex McHugh wrote:

> do I have to go with the "code exceptions for each attribute" approach?


I'd go for a configurable generic code exception approach.

- Define the list of attrs as a GCV or in a mapping table, whatever is
convenient.
- Read that list into a nodeset var (GCVs are easier here, I can share a piece
of code to load a mapping table into a usable nodeset if you need to go that
way)
- in your code refer to the var instead of coding real attr names. Something
like the following in an IT should work for incoming modifies of associated
objects:

for each xpath .//*[@attr-name=$var]/@attr-name
var current-attr=$current-node
strip-op-attr $current-attr$
clear src-attr $current-attr$
for each dest-attr $current-attr$
add-src-attr $current-attr$=$current-node$

You'll need some more code to make merges work the way you want, of course.

Have fun, Lothar
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Fooling the merge process.

Lothar Haeger wrote:

> Alex McHugh wrote:
>
> > do I have to go with the "code exceptions for each attribute"
> > approach?

>
> I'd go for a configurable generic code exception approach.
>
> - Define the list of attrs as a GCV or in a mapping table, whatever is
> convenient.
> - Read that list into a nodeset var (GCVs are easier here, I can
> share a piece of code to load a mapping table into a usable nodeset
> if you need to go that way)
> - in your code refer to the var instead of coding real attr names.
> Something like the following in an IT should work for incoming
> modifies of associated objects:
>
> for each xpath .//*[@attr-name=$var]/@attr-name
> var current-attr=$current-node
> strip-op-attr $current-attr$
> clear src-attr $current-attr$
> for each dest-attr $current-attr$
> add-src-attr $current-attr$=$current-node$


Thanks for the pseudo-code, it reminded me that I'd actually solved a
similar case (but for one attribute and with some extra twists) on
another project long ago. So I dug that code up and used that as a
basis.

> You'll need some more code to make merges work the way you want, of
> course.


Yeah also working on that.


--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.