Let's have a multi-domain AD deployment. You can think of it as an LDAP topology with a top-level suffix on one server and sub-suffix on another server. In AD the entries are identified by GUID. You can think of it as an AD equivalent to LDAP entryUUID. So, obviously the GUID is used as ConnId _UID_. This is good, because we can easily detect renames, moved accounts and so on.
But, in multi-domain topology there is a problem. GUIDs are similar to UUIDs: they are pseudo-random. If you have just GUID then you have no idea on which server the entry resides. And this is quite unfortunate, because _UID_ is the primary identifier for almost all ConnId operations .... I will skip some details here. But there is no good way how to do this in the current ConnId. What we need is DN. But if we switch ConnId _UID_ to hold DN instead of GUID then we pretty much lose the ability to detect renames and moves. Bad situation.
However, every self-respecting IDM system keeps both primary idenfier (_UID) and secondary identifiers (NAME_). So why not send both to the ConnId operations? The _UID_ is obviously the primary authoritative identifier. But we can also send _NAME_ as a hint. That can be used to route the request and that routing will be precise in most of the cases. Then it is not that bad if we implement some fallback brute-force mechanism for the rare cases when the DN has been changed in the meantime.
The trouble is that adding both _UID_ and _NAME_ to the existing methods will break compatibility. But there is a way around that. We can add _NAME_ as an optional property of the org.identityconnectors.framework.common.objects.Uid class. That won't change the signature of existing method. It won't break existing connectors. And the connectors that need that can take advantage of that and operate efficiently.
This approach can even solve a different problems: renames. Currently the update() operation returns only Uid. But if the operation changes both _UID_ and _NAME_ there is no way how the connector can indicate that. If we add the "name hint" into the Uid class then where would be a way.
And it solves yet another problem: CONTAINER option. Currently the container option needs QualifiedUid which is also UID. But in LDAP and AD this means entryUUID and GUID respectively. That is pretty much useless as a base context specification. DN is needed there. Of course, the connector may translate entryUUID/GUID to DN, but that is additional roundtrip (or roundtrips) and it absolutely kills the performance. Adding name hint to Uid would also solve this issue.
Thanks for the PR,
Bulk close for 126.96.36.199