I could use a little help understanding why my prototype eDir-to-eDir
driver is working the way it is. The general idea is to allow the
Identity Vault (Driver A) to push several attributes (such as title)
down to the non-authoritative source App Directory (Driver B) on merge
or modification. Future modifications of title in Driver B are ignored.

As a general approach, I am attempting to leave Driver B 'dumb'. In
other words, all the logic is contained in Driver A. Driver B will be
broadcasting all it's attributes and accepting all attributes from
Driver A. Driver A is where security is enforced at the filter and
logic is implemented. I think this makes sense from a security and
design perspective, though I can be convinced otherwise if there are
compelling reasons.

Title is a multi-valued attribute which I am testing the design with.

*IDVault / Driver A:* eDir 8.8, IDM 3.6, Filter: Sync Title on
Subscriber, Ignore on Publisher, Merge Authority: default
*App Dir / Driver B:* eDir 8.8, IDM 3.5.1, Filter: Sync Title on
Subscriber & Publisher, Merge Authority: default

*Scenario 1:* A new user is added to the Identity Vault (Driver A) and
there is a pre-existing user in the App Directory (Driver B). A match
occurs and the title from the IDVault is added to the multi-vallued
attribute in the App Directory. The user now has two titles in the App
Dir. The This makes sense and I can sleep at night.

*Scenario WTF???* A new user is added to the App Dir (Driver B) and a
pre-existing match resides in the ID Vault. A match occurs. The title
of the user in the App Dir account is now -overwritten - with the title
from the ID Vault, and it is not added as an additional value.


JoelCBennett's Profile:
View this thread: