Identity Broker for NIM requires a permanent, unique key be specified for associations

Nick - do I take it that the dn in the connector appears something like UID=<IdB guid>?
If so, then I totally can see how this causes issues and is why I usually opt for the alternative of declaring an alternative DN in the adapter (e.g UID=<chris21 employeeID>,OU=Users). This works well from an import perspective, but may cause problems on export ... I don't know. The benefit of this approach is that you keep the anchor as a dn, but it doesn't change when you clear out the connector space. I personally think using the IdB guid as the anchor is a flawed approach because of your problem ... unless the identity engine (FIM/NIM etc) can do what FIM calls a "delete-add" operation, resulting in no net change. I suggest you explore the alternative dn idea with Patrick ... let me know how you go, as this is the way I have generally worked lately with IdB and FIM, and there might be some downsides.

Hey Bob, exactly my issue. Basically I need an anchor that doesn't change. Assuming I can set an alternative one as you suggest, I think that will work.

Hey Nick, I am pretty sure we saw the same thing at GCCC and Ross changed the config in IdB to do exactly that - using detnumber as the uid. Maybe ask him if he has a copy of the config.

Updated issue type.

Hi Nick,

As Bob and Eddie correctly pointed out, using a DN generator to create a DN based on unique key fields is the way to resolve this issue. It was not available in v2.x which is probably why you haven't encountered it before. The only thing I would add to Bob's comment is that he referred to the default, entity ID approach as "flawed" - this is correct, but in the sense that it's not really intended to be used in any situation. It's only there because we don't have enough information to use any other DN as the default. As such, any time you create an adapter I'd suggest you use a generator.

The documentation for this is available here: https://unifysolutions.jira.com/wiki/display/IDB306/Distinguished+Name+generators

If you need some assistance or would like some sample configuration, feel free to come and ask in-person any time during the week.

The appropriate change has been made, and adapter entities are now appearing with a more suitable DN.

However, it appears as if there are still two problems

• Firstly, the id being presented to NIM is still the entity ID. As a result, clearing Identity Broker (intentionally or otherwise) will mean that new ids are generated in the future which will cause serious problems.
• Secondly, that Identity Broker for NIM may not have the ability to use the "migrate" functionality. From talking to Nick I believe what we need is the ability to present all information as "new" to NIM. Not sure yet how this is done at a code-level.

As Shane has now passed off all his NIM knowledge to the Product Group and our documentation, I'll have to work with Tony on this. I'll endeavour to do this as soon as Tony's current issue is complete, but I would expect that some level of NIM expertise will be required from Nick or Eddie.

Updated title, other info.

Hi Nick,

I've completed as much of the modifications you requested as possible - enough to give it another test in your environment (provided your adapter is not using any composite or multi-valued keys). However, there are some problems, which with Eddie's help I've been able to narrow down and identify as follows.

The reason the entityId works so well (for us) as the association is because it is unique across all adapters, and all object types within a particular composite adapter. This is not the case with a particular id like "1", which may be a unique key across different object types in a composite adapter.

In FIM this is not a problem, as when we export the object class associated with the object is already included. This is not the case with NIM "modify", "query" or "delete" operations, so we have no way of knowing.

Due to your deadlines with SA Water, I'm after the quickest possible fix to get you through with the full intention of having a discussion in the future to fully review the design of the NIM adapter. So, for the time being, I believe we can do one of two things:

1. Prohibit the use of a composite adapter. If there's no composite adapter, there's only one object class so we don't need to know what it is because only one will exist inside the adapter. I don't know if you're using a composite adapter - if you're not, my modifications are complete and you can test it as soon as possible. If you do require a composite adapter, then we need look at...
2. Modify the XML that NIM sends to Identity Broker for "Query", "Modify" and "Delete" to include the object type along with the association id. Eddie has told me this is possible (with one limitation, can discuss in person) and he can potentially assist us if necessary. This will rely on me making further modifications to the NIM adapter once I know what this new XML will look like. Whilst more robust, I imagine it will require at least a few hours effort from each of us.

If you're in the office tomorrow then we should sit down first thing and discuss these options and what will best work for you and SA Water.

Provided fix has appeared to work for the non-composite adpater. Having a slight problem with packing up a formal installer, but will endeavour to fix this and provide by Monday.

Hi Nick,

Tony has uploaded the 3.0.5.2 installer for you to use at SA Water. Please close this issue once you're satisfied the changes we've made will get you through the rest of the project.

Re-opening to correct Billing Key