Feature request: Identity Broker 5.2 object filtering facility
Adrian Corston 5 years ago • updated by Matthew Davis (Technical Product Manager) 3 months ago • 10
I needed to filter a subset of objects from one connector or adapter (i.e. All Organisation Unit objects) to create separate connectors or adapters for just those objects (i.e. All Business Units).
There does not seem to be any way to filter using Broker's built-in functionality, so the solution I chose was to write a powershell script to perform an LDAP query against Broker and populate a new connector based on the selected subset of objects.
Please consider adding this functionality (or something equivalent) to the base Identity Broker product.
Customer support service by UserEcho
For reference, the aforementioned powershell script is reproduced below:
Filtering entities is generally considered to be the concern of the connector. Which connector are you dealing with?
A custom REST API connector. At this time he is not able to add filtering functionality.
It seems to me that it would be more efficient and sensible to add generic object filtering in the core Identity Broker product, rather than expecting every connector to implement it's own object filtering time and time again.
The reason filtering is generally considered a concern of the connector is that the connector is usually able to perform the filtering via targeted imports, pulling in only the required entities and reducing the size and duration of the import. Downstream identity management systems also typically have filtering capabilities, so we haven't yet found compelling business value in adding this to the product.
This feature is on our backlog, so I've added a reference to this ticket there so it can be prioritised appropriately.
Adrian, could you please supply a data model for what you're trying to achieve? There may be a more suitable set of transformations that will achieve it.
We get back a "jagged" (apparently that is the technical term for it) heirarchy of organisational unit objects as a flat data set where each node in the heirarchy has an ID and a reference to it's parent node via ID. Each node has a level (e.g. "Business Unit", "Program", "Group", "Team").
Different parts of the tree have different parent level structures. For example, one part of the heirarchy might be: Business Unit X -> Program Y -> Team Z, and another might be Business Unit X -> Group A -> Team B. For any node, however, the path to the root of the heirarchy is fixed and consistent.
The heirarchy structure has some other complexities. Firstly, the same ID may be used by different nodes at different levels. So for example, Business Unit A -> Program B -> Team B (i.e. Program B and Team B use the same node ID). Secondly, sometimes the parent of an object of a given type may be another object of the same type, e.g. Business Unit A -> Program B -> Program C -> Team D.
It's about as chaotic a heirarchy tree as you could ever hope for...
The key business requirement for this data is to automatically provision AD groups (with attributes that differ by object type, based on a set of rules) with criteria based membership.
For each Team, provision a AD group with these attributes:
* DisplayName = <BusinessUnitName> <TeamName>-DG
* Type = Distribution
* Members = All users matching the Team's <TeamCode>
* etc etc.
The difficulty here is that the BusinessUnitName that is required for the DisplayName comes from a parent up the "jagged" heirarchy above the Team object. So for every Team (etc) object we have to walk the organisational object heirarchy (with all it's parent ID linking complexities) until we find the corresponding BusinessUnit object, then copy that object's BusinessUnitName attribute into our Team object.
This complex manipulation is really not something that Broker's joins are capable of doing :-)
Note: This ticket ONLY relates to the question of creating a container of object of a given type (level). The bigger issue (of walking the organisational structure to extract the Business Unit Name) is not what I'm asking about - I have already coded a solution for that.
This sounds extremely similar to the example underneath "Transformation Combinations" on Common Transformation Scenarios. Please take a look there to see if any techniques described might be useful to your data model.
Please re-read my comment - the simple approach documented on that page isn't able to handle the complex details of the requirements.
Could you please clarify a few details that were glossed over a little in your comment?
1. No, all levels must be exposed as different objects
2. It would be reasonable to assume depth <= 6
3. Yes. No.
5. Yes. The parent is the node with the largest level ID, unless that node is the current node.