We are using the Nexus product (Open Source - thanks Walter) at Rice.
While Nexus does a great job of provisioning, we still needed to have a
Person Registry which is where the join occurs and as David points out,
where the record of all reconciled person information resides. The
person registry is the part that we wrote and does the heavy lifting of
reconciling people to accounts from various sources. Mark has actually
written a very nice one that is available on the NMI-Edit site (correct
me if I am wrong Mark) and it can take any number of sources and create
Jones, Mark B wrote:
> One term used for this is "The Join".
> We (UT Houston HSC) wrote our own.
> There are off-the-shelf products that claim to do this but from what I have
> seen they only provide a framework that requires you to invest as much
> effort configuring as it would to write your own.
> I believe that the Nexus project may be an up and coming open source
> solution for this. (http://www.nmi-edit.org/releases/index.cfm#Nexus)
> I'll answer your questions inline.
> -----Original Message-----
> From: Benn Oshrin [mailto:[log in to unmask]]
> Sent: Thursday, June 08, 2006 2:11 PM
> To: [log in to unmask]
> Subject: [IDM] Person/Identity Matching
> One of the issues we're about to (re)examine here is matching people who
> come from multiple sources.
> A typical case is a student who we already know about from the student
> system gets hired as a casual or work study employee, and we want to make
> sure their information from the personnel system gets attached to their
> existing identity rather than have a new (second) identity created for them.
> We already perform weak matching that catches most cases, but we are
> looking to signficantly improve our handling of these individuals. We
> would prefer to get a better idea of what others are doing before we make
> our plans, and so I'd like to throw out a few questions to the list.
> 1. Did you write your own matching algorithms or do you use a
> vendor solution?
> Wrote our own.
> 2. If you wrote your own, what criteria do you match on?
> System of Record generated identifier (employee number etc.)
> Any other unique identifier the SOR may store such as driver license
> First and Last name
> Birth information (Date, place (city), and country)
> 3. If you use a vendor solution
> a. Which one do you use?
> b. Is it a full vendor implementation, or do you just call
> hooks from your own existing applications?
> c. Who implemented your solution? (vendor, consultants, staff,
> I have not seen a vendor solution that really does this but you
> might investigate Novell Identity Manager. It may come close. We use it to
> populate AD and Exchange from our Enterprise Directory. It was implemented
> by our staff.
> 4. What has been your success rate with your implementation?
> We have been very successful. Our rate of duplicate accounts is
> very low and the administration required to reconcile possible duplicate
> accounts is very manageable.
> 5. What are your procedures for handling close/multiple potential
> Possible or multiple matches are flagged for manual reconciliation
> before the account is created. We have an administrator that investigates
> these matches before allowing account creation to proceed.
> 6. What are your procedures for recovering incorrect matches?
> This is normally caused by data entry error in the SORs or human
> error during manual reconciliation. Once the SOR data is corrected the data
> for the distinct persons is manually separated.
> 7. If not otherwise covered above, what are the interfaces to your
> system? (manual data entry via web, batch feeds, real time api,
> We get daily batch feeds from all SORs. Manual identity
> reconciliation and management of the person registry is done via a secure
> Web application.
> I will summarize off-list replies.