Recientemente, he estado involucrado en varios proyectos de clientes que implican la distribución y sincronización de cuentas de usuario entre múltiples organizaciones. Esto es un poco diferente del escenario de sincronización estándar, que asume que hay una organización, y los datos fluyen desde una fuente autorizada, como un almacén de datos de RRHH. Un ejemplo de esta sincronización básica se puede ver en la Figura 1; supongamos que tenemos tres dominios en nuestra organización, y el dominio A es autoritativo.
En este escenario básico, la precedencia de atributos no es una consideración, porque sólo hay un flujo de importación para todos los atributos de objetos persona (véase la Figura 2).
Obviamente, las cosas rara vez son tan sencillas, incluso en un entorno básico. Normalmente, hay al menos unos cuantos atributos que tienen flujos de importación de más de una fuente. Un ejemplo sencillo podría ser displayName. "William" puede ser su nombre oficial, pero todo el mundo lo conoce por "Bill", y nadie puede encontrarlo en la libreta de direcciones. Por tanto, la fuente de RR.HH. puede rellenar ese atributo al principio, pero después, su dominio AD actualizará el atributo displayName en función de las preferencias del usuario.
En el ejemplo de la Figura 3, puede hacer que el dominio A sea autoritativo para el atributo displayName en la carga inicial (o provisión), y después hacer que el dominio B sea autoritativo para ese atributo moviendo la MA para B por encima de A en la configuración de Precedencia de Flujo para ese atributo (ver Figura 4).
Este tipo de precedencia de atributos es fácil de configurar siempre y cuando tenga atributos de usuario que fluyan en una dirección.
Antes de continuar, creo que es importante recordar cuándo se determina la precedencia de los atributos en la sincronización FIM:
La prioridad se determina en el flujo en el metaverso FIM
Es importante recordar que la precedencia de los atributos no se determina durante la exportación desde el Metaverso, sino en la importación al Metaverso. Comprender esto es fundamental.
Entonces, ¿qué ocurre con la precedencia de atributos cuando se tienen objetos de usuario que deben poblarse de forma cruzada a través de la sincronización?
En la figura 5, cada dominio tiene su propio conjunto de objetos de usuario únicos que deben sincronizarse con los demás dominios.
Utilizar la precedencia simple de atributos ya no funcionará; cada dominio es autoritativo para los atributos de su usuario. Por ejemplo, si tiene configurada la precedencia simple de atributos A, B, C, un objeto persona de Metaverso procedente del dominio A funcionará perfectamente: el objeto persona será actualizado por el dominio A (porque es precedente) durante la importación - y esos atributos se exportarán a los dominios B y C (véase la Figura 6).
Pero, ¿qué ocurre cuando se desea sincronizar un objeto de usuario único del dominio B con el dominio A? Una vez que el objeto está conectado a ambos dominios, el dominio A pasará a ser el precedente para los atributos. Observa en la Figura 7 que, aunque el usuario procede del dominio B, el dominio A es ahora autoritativo para el atributo displayName debido a su posición en la configuración de precedencia de la Figura 6.
Hay un par de enfoques diferentes para manejar esto:
Flujos avanzados para todas las importaciones de atributos
Un enfoque consiste en escribir código de extensión para cada flujo de importación en el metaverso FIM.
La ventaja es que sólo tiene que ocuparse de un objeto (persona) en sus flujos de exportación a cada MA conectada. Esto puede ser útil si tiene otras 20 o 30 MA (hace poco tuve un cliente que tenía más de 60).
La desventaja es que ahora tiene que tratar con flujos avanzados (y la codificación de extensión obligatoria) para cada flujo de importación. Si quiere añadir o modificar un flujo más adelante, tendrá que modificar el código de extensión para cada MA fuente afectada. Esto hace que sea un poco difícil de entregar a su equipo de mantenimiento.
Un objeto del Metaverso para cada MA
Otro enfoque consiste en crear un objeto "persona" para cada AM.
La ventaja es que sólo hay una importación en cada objeto (el dominio de origen), por lo que la precedencia de atributos no es un problema.
La desventaja es que ahora hay que definir cada objeto en los flujos de exportación. De nuevo, un verdadero problema si se trata de un gran número de MA conectadas (véase la Figura 11).
Además, si quiere añadir un atributo a los flujos de sincronización (digamos que ahora quiere hacer fluir ipPhone desde/a todos los dominios) necesitaría modificar potencialmente [número de MAs]2 elementos de configuración.
...
Cada una de estas soluciones es viable y tiene sus pros y sus contras. Pero hay otra solución que es un poco híbrida y que evitará tanto la codificación de extensión para las importaciones directas como la necesidad de definir un objeto para cada MA.
Ahora bien, si la situación es que cada fuente tiene objetos únicos que deben sincronizarse con todas las demás MA, entonces una de las opciones anteriores es la única forma de hacerlo. Pero si se da el caso de que la mayoría de las fuentes deben sincronizarse sólo con un subconjunto de las otras AM (típico durante las adquisiciones y fusiones, así como en las relaciones de empresas paraguas), entonces el siguiente enfoque puede ahorrar algo de tiempo.
Un objeto Metaverse para las AM que tienen varias exportaciones
En este ejemplo, supongamos que la empresa "C" ha adquirido las empresas "A" y "B". En este caso, todos los usuarios deben aprovisionarse en el dominio C para acceder al correo electrónico y a las aplicaciones, y los usuarios del dominio C necesitan acceder a las aplicaciones de los dominios A y B (figura 12, a continuación).
Si se observa el diagrama de la Figura 12, se crearía un objeto "persona" del Metaverso para cada MA que tuviera varias flechas de entrada; en este caso, el dominio C (véase la Figura 13).
Las ventajas son que podrá:
- Evite la codificación de extensión para flujos directos (recuerde que, aunque el objeto persona tenga flujos de importación tanto de A como de B, nunca estarán conectados entre sí, por lo que la precedencia no es un problema).
- Sólo hay que definir los flujos de exportación para el objeto persona y las pocas AM para las que se necesita crear un objeto persona único en el Metaverso (en este caso el dominio C)
- Reducir la complejidad de futuros cambios.
Como puede ver, si ahora quisiera hacer fluir el atributo ipPhone en este escenario, en lugar de modificar el cuadrado de las AM implicadas, sólo tendría que modificar los elementos de configuración [número de objetos persona] x [número de AM] (6 elementos en lugar de 9).
Una vez más, probablemente no es un gran problema si se trata de tres o cuatro MA - pero si usted está en una situación en la que está tratando con más de unos pocos, entonces esta técnica podría ahorrar algo de tiempo; si usted tiene 14 MA y añadir un atributo a su ámbito de aplicación, haciendo 28 cambios seguro que es mejor que hacer 196.
(142 = 196 , ¡pero 14×2 son sólo 28!)
