Join Rules

Introduction

Panel platform includes a Join Rule framework for connecting silos together across different providers. Join rules can be created to connect silos between different providers to create a single unified Time Traveller view.

Different silos within a single provider are implicitly joined based on the rules of the underlying system. In the Sync Engine provider, CS and MV objects are linked based on the joins in MIM/FIM..., in the Azure AD provider, MSOnline and Exchange objects are linked based on the online Identity.

The Join Rule engine is used to create relationships between objects that are not otherwise connected. When objects are joined, links within a provider are automatically traced.

For example supposing the following two providers:

FIM

HR — Metaverse — Active Directory

Azure AD

MSOnline — Exchange

If you create a rule that connects Active Directory to Exchange based on the mail attribute, then when you view an object in the MSOnline silo, relationships will be implicitly traversed to show the HR and other silos.

Another way to use join rules is to create additional relationships within the same provider. For example, join rules could be used to view regular user accounts side-by-side with privileged accounts belonging to the user.

There are a couple important implementation differences between Panel platform join rules and MIM/AADSync/FIM/DirSync join rules. In the Microsoft Sync Engine, joins are created as permanent links between CS and MV objects. However, in Panel platform, there is no concept of joins as actual persistent links between silos. Instead, join rules create pre-calculated indexed fields on the Object Record, and when you view objects in the Time Traveler queries are made for other objects that have the same indexed join value.

In Panel platform a Join Rule consists of a Rule Engine rule that takes the Object Record as input, and produces a unique index value. To join different silos, each silo must have a join rule that produces the same value for related objects. These join link are not persistent, and are always based on the most recent version of the object.

images/join_rules.png

Join rule values are calculated and indexed whenever an object is created or modified. In addition, it is possible to instruct Panel platform to retro-actively process existing objects and re-calculate join rules. This allows join rules to be created and added without re-scanning data.

Join Rule Settings

It is possible to create as many join rule relationships as desired.

The first part of a join rule is the scope filtering. Each rule must indicate the silo and object type that triggers its evaluation. There is no limit on the number of rules that may be created for the same silo and object type.

  • Scope / Silo: Required — Silo containing objects that this rule applies to.
  • Object Type: Required — Objects within silo to apply rule to.

The second part of a join rule is the indexed value. This consists of a target calculated object type, attribute name, and attribute value. In order to establish a relationship, all three values must match, regardless of object types in the source systems.

  • Target Object Type: Required — Name of virtual object representing the join relationship.
  • Target Attribute: Required — Name of virtual attribute to scope the calculated value.
  • Value Rule — Required — Rule engine logic to produce the actual join value. Join rules should produce values that are unique within a silo and object type.

After making and saving changes to Join rule settings, the "Apply Rules" button may be pressed to iterate through existing objects and update indexed join values. Depending on the size of the data-set and hardware performance, this operation may take anywhere from a few seconds to tens of minutes.

Once join rules have been established, silos will appear side-by-side in the Time Traveller, regardless of Provider of origin.

Copyright © SoftwareIDM

Table of Contents