In letzter Zeit habe ich an mehreren Kundenprojekten mitgewirkt, bei denen es um die Verteilung und Synchronisierung von Benutzerkonten zwischen mehreren Organisationen ging. Dies unterscheidet sich ein wenig vom Standardszenario der Synchronisierung, bei dem von einer einzigen Organisation ausgegangen wird und die Daten von einer maßgeblichen Quelle, z. B. einem HR-Datenspeicher, stammen. Ein Beispiel für diese grundlegende Synchronisierung ist in Abbildung 1 zu sehen. Angenommen, wir haben drei Domänen in unserer Organisation und Domäne A ist maßgeblich.
In diesem Basisszenario spielt der Vorrang von Attributen keine Rolle, da es nur einen Importfluss für alle Attribute des Personenobjekts gibt (siehe Abbildung 2).
Offensichtlich sind die Dinge selten so einfach - selbst in einer einfachen Umgebung. In der Regel haben Sie mindestens einige Attribute, die Importflüsse aus mehr als einer Quelle haben. Ein einfaches Beispiel hierfür ist displayName. "William" mag sein offizieller Name sein, aber jeder kennt ihn unter "Bill", und niemand kann ihn im Adressbuch finden. Der HR-Feed kann dieses Attribut also zunächst auffüllen, aber danach wird Ihre AD-Domäne das Attribut displayName auf der Grundlage der Benutzerpräferenzen aktualisieren.
Im Beispiel in Abbildung 3 könnten Sie Domäne A beim ersten Laden (oder Bereitstellen) für das Attribut displayName autorisierend machen und danach Domäne B für dieses Attribut autorisierend machen, indem Sie den MA für B über A in der Flusspräzedenzkonfiguration für dieses Attribut verschieben (siehe Abbildung 4).
Diese Art von Vorrang der Attribute ist einfach zu konfigurieren, solange die Benutzerattribute in eine Richtung fließen.
Bevor ich fortfahre, ist es wichtig, daran zu erinnern, wann der Vorrang von Attributen bei der FIM-Synchronisierung festgelegt wird:
Der Vorrang wird für den eingehenden Fluss in das FIM-Metaverse
Es ist wichtig, sich daran zu erinnern, dass der Vorrang der Attribute nicht beim Export aus dem Metaverse, sondern beim Import in das Metaverse festgelegt wird. Dies zu verstehen ist der Schlüssel!
Wie sieht es also mit dem Vorrang von Attributen aus, wenn Sie Benutzerobjekte haben, die über die Synchronisierung mit anderen Objekten ausgetauscht werden müssen?
In der obigen Abbildung 5 hat jede Domäne ihren eigenen Satz eindeutiger Benutzerobjekte, die mit den anderen Domänen synchronisiert werden müssen.
Die Verwendung der einfachen Attributspriorität funktioniert nun nicht mehr; jede Domäne ist für die Attribute ihres Benutzers maßgebend. Wenn Sie beispielsweise die einfache Attributspriorität A, B, C eingestellt haben, funktioniert ein Metaverse-Personenobjekt, das aus Domäne A stammt, einwandfrei: Das Personenobjekt würde während des Imports von Domäne A aktualisiert (da sie Vorrang hat) - und diese Attribute würden in die Domänen B und C exportiert (siehe Abbildung 6).
Aber was passiert, wenn Sie ein eindeutiges Benutzerobjekt aus Domäne B mit Domäne A synchronisieren möchten? Sobald das Objekt mit beiden Domänen verbunden ist, wird Domäne A für die Attribute maßgebend. In Abbildung 7 sehen Sie, dass, obwohl der Benutzer aus Domäne B stammt, Domäne A aufgrund ihrer Position in der Vorrangkonfiguration in Abbildung 6 nun für das Attribut displayName maßgebend ist.
Es gibt verschiedene Möglichkeiten, dies zu tun:
Erweiterte Abläufe für alle Attributimporte
Ein Ansatz besteht darin, Erweiterungscode für jeden einzelnen Importfluss in das FIM-Metaverse zu schreiben.
Der Vorteil ist, dass Sie nur ein Objekt (Person) in Ihren Exportströmen zu jedem angeschlossenen MA bearbeiten müssen. Das kann praktisch sein, wenn Sie 20 oder 30 andere MV haben (ich hatte kürzlich einen Kunden, der über 60 hatte).
Der Nachteil ist, dass Sie nun für jede Importbewegung mit erweiterten Bewegungen (und dem obligatorischen Erweiterungscode) arbeiten müssen. Wenn Sie später einen Fluss hinzufügen oder ändern wollen, müssen Sie den Erweiterungscode für jede betroffene Quell-MA ändern. Das macht es ein wenig schwierig, das Projekt an Ihr Wartungsteam weiterzugeben.
Ein Metaverse-Objekt für jeden MA
Ein anderer Ansatz besteht darin, für jeden MA ein Objekt "Person" zu erstellen.
Der Vorteil hierbei ist, dass es nur einen Import in jedes Objekt (die Quelldomäne) gibt; daher ist die Vorrangigkeit der Attribute kein Problem.
Der Nachteil ist, dass Sie nun jedes Objekt in Ihren Exportflüssen definieren müssen. Auch dies ist ein echtes Problem, wenn Sie mit einer großen Anzahl verbundener MAs zu tun haben (siehe Abbildung 11).
Wenn Sie ein Attribut zu den Synchronisierungsströmen hinzufügen möchten (z. B. wenn Sie ipPhone von/nach allen Domänen senden möchten), müssen Sie möglicherweise die Konfigurationselemente [Anzahl der MAs]2 ändern.
...
Jede dieser Lösungen ist praktikabel, und jede hat Vor- und Nachteile. Es gibt jedoch noch eine weitere Lösung, die eine Art Hybrid ist und sowohl die Codierung von Erweiterungen für direkte Importe als auch die Notwendigkeit, ein Objekt für jede einzelne MA zu definieren, vermeidet.
Wenn nun jede einzelne Quelle eindeutige Objekte hat, die mit jeder anderen Hauptverwaltung synchronisiert werden müssen, dann ist eine der oben genannten Optionen die einzige Möglichkeit, dies zu tun. Wenn Sie jedoch ein Szenario haben, in dem die meisten Quellen nur mit einer Teilmenge der anderen Hauptverwaltungsbehörden synchronisiert werden müssen (typisch bei Übernahmen und Fusionen sowie bei Beziehungen zwischen Dachgesellschaften), dann kann dieser nächste Ansatz etwas Zeit sparen.
Ein Metaverse-Objekt für MAs, die mehrere Exporte haben
In diesem Beispiel nehmen wir an, dass Unternehmen "C" die Unternehmen "A" und "B" übernommen hat. In diesem Fall müssen alle Benutzer für den E-Mail- und Anwendungszugriff in Domäne C bereitgestellt werden, und die Benutzer von Domäne C benötigen Anwendungszugriff auf Domäne A und Domäne B (Abbildung 12, unten).
Betrachtet man das Diagramm in Abbildung 12, so würde man für jede MA, die mehrere Eingangspfeile hat, ein Metaverse-Objekt "Person" erstellen; in diesem Fall also die Domäne C (siehe Abbildung 13).
Die Vorteile sind, dass Sie in der Lage sind:
- Vermeiden Sie Erweiterungscodierung für direkte Flüsse (denken Sie daran, dass das Personenobjekt zwar Importflüsse von A und B hat, diese aber nie miteinander verbunden sind, so dass der Vorrang keine Rolle spielt)
- Sie müssen nur Exportflüsse für das Personenobjekt und die wenigen MAs definieren, für die Sie ein eindeutiges Metaverse-Personenobjekt erstellen müssen (in diesem Fall Domäne C)
- Verringerung der Komplexität künftiger Änderungen.
Wie Sie sehen, müssten Sie, wenn Sie das ipPhone-Attribut in diesem Szenario fließen lassen wollten, statt das Quadrat der beteiligten MV zu ändern, nur [Anzahl der Personenobjekte] x [Anzahl der MV] Konfigurationselemente ändern (6 Elemente anstelle von 9).
Auch dies ist wahrscheinlich kein großes Problem, wenn Sie mit drei oder vier Hauptverwaltungsräten zu tun haben - aber wenn Sie in einer Situation sind, in der Sie mit mehr als ein paar zu tun haben, dann könnte diese Technik etwas Zeit sparen; wenn Sie 14 Hauptverwaltungsräte haben und ein Attribut zu Ihrem Geltungsbereich hinzufügen, ist es sicher besser, 28 Änderungen vorzunehmen als 196.
(142 = 196 , aber 14×2 ist nur 28!)
