Identity Broker Forum
Welcome to the community forum for Identity Broker.
Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.
Configuration guidance required
In a UNIFYConnect ABAC solution we use appointment information (i.e. a user's Employee ID, Position, Department, Team, Location and Start Date) along with customer-managed rules in order to determine which access packages the user should be automatically assign to.
My customer has two sources of appointment information: one is directly on the employee, and the other is via a separate feed of secondary appointments. Each employee has one primary appointment and zero or more secondary appointments.
In order to combine the appointments into one data source, I use the following paths into the Appointment locker:
Employee connector/adapter -> link -> Appointment locker
Secondary appointment connector/adapter -> link -> Appointment locker
The employee connector is keyed solely on Employee ID, but the Secondary appointment connector is keyed on Employee ID, Position, Department, Team, Location and Start Date, to guarantee uniqueness.
On the outgoing side the following path writes the combined Appointments to a CSV file for processing outside of UNIFYBroker:
Appointment locker -> link -> Appointments CSV connector/adapter
The Appointments CSV connector is keyed on Employee ID, Position, Department, Team, Location and Start Date, to guarantee uniqueness.
All links use connection-oriented join resolution.
When an existing Employee connector entity changes Department, Team (etc) the existing Appointment locker record is updated with new values for those fields. For the export to the Appointments CSV connector, this causes a problem because that update is processed as an anchor modification, which is not supported for CSV connector types.
This problem doesn't occur on the Secondary appointments connector, because the multi-part key ensures that changes to any key field results in a delete/add operation instead of an update.
How can I configure UNIFYBroker to make this scenario work correctly?
Hi Adrian
Creating a derived key generated from adapter transformations might help.
For the secondary appointment entities, use a PowerShell transformation to generate a unique value based on the Position, Department, Team, Location and Start Date fields that persists their uniqueness quality, but reduces them to a single field. A hash of some kind of their combined values should be sufficient. I'd also add a static prefix for a further uniqueness guarantee. The resulting value may look something like like sec_c9uQNFGLgC.
On the primary adapter, use a constant value transformation to add a derived key field to differentiate primary appointments from secondary ones. The value set can by anything, but shouldn't be anything that could be generated by the transformation on the secondary appointment adapter, ie: primary_appointment.
Use the derived key in conjunction with the EmployeeId field for link joins and as key fields on the Appointments CSV connector. This should provide a stable, two-field anchor based on the immutable secondary appointment properties, but not the mutable properties of the primary appointment.
Adapter data not mapping to locker during baseline sync
Some adapter field data isn't being updated in their locker entity when a baseline sync is run.
Screen snaps will be in a follow-up comment.
Exclusion group not stopping connector import/export operations from running in parallel
I have three connectors in an exclusion group, and yet imports on one connector in the group can run at the same time as exports on another connector in the group. Exclusion groups should stop this from happening, to avoid two operations (Aurion API calls in this case) from both taking place at the same time.
Hi Adrian,
Exclusion groups are only capable of blocking for import operations (see Connector Overview / UNIFYBroker knowledge / UNIFY Solutions for more details).
Connectors don't control the invocation of the export capability, as this is triggered by external processes (generally an identity management system through a Gateway, or more recently through UNIFYBroker/Plus Link operations).
Export operations are designed to provide immediate communication with the external system, due to the way Gateways are required to communicate the operation status rather than queuing it for a later execution.
If you'd like, we can have some discussions about the role an export exclusion capability would play in the UNIFYBroker/Plus ecosystem? It would require careful consideration to ensure we don't impact the correct function of gateways. In an ideal scenario you would line your import and link schedules up so they don't overlap, but I understand this can be difficult in complex configuration scenarios.
Change Polling sometimes doesn't run when there are pending changes
Occasionally Change Polling won't start, even though there are pending sync changes showing. Running a Baseline Sync clears the issue and subsequent changes make Change Polling work normally, so the workaround is to always have periodic Baseline Syncs scheduled in the solution.
Sadly, I have no idea what causes this or how to replicate it so it is likely to be quite difficult to track down.
Entities keep reprovisioning for Simple Join Resolution links
Using a link with Simple Join Resolution I see the same target entity being re-provisioned every time the Baseline Sync runs.
The problem continues until the duplicate detection algorithm fails to generate unique values for key fields like CN.
I'll put environment details and logs in the next comment.
UNIFYBroker/Plus attempting to join source to incorrect target
Log says:
20221129,21:30:25,UNIFYBroker,Link,Error,"Request to sync changes on link failed. Request to sync changes on link Employee > AD User (ad53013b-b271-4ed6-a959-dc11aeaa5eca) in direction outgoing failed with message Source entity '0b5d5a72-fd60-4777-b1ef-f1d4a035c87d' cannot be joined to ambiguous join targets: [391e6395-a3c2-424c-9799-30a98508ac1f, 5a6e4486-75f8-4487-ab8f-4eeccf06a524]. Cannot proceed with join. [Count:4321]. Duration: 00:00:04.5645340
Link join criteria is:
Source entity is:
Target entities are:
Why would an attempt to join to 5a6e4486-75f8-4487-ab8f-4eeccf06a524 be happening, given it doesn't match the join criteria?
The root cause of this was staff from the customer's outsourced IT department updating employeeID values wrongly, in contravention of documented processes.
Please close this ticket and mark 'not a bug'.
Join calculation for source entity cannot be completed due to an invalid connection state. Reason: Source entity has multiple connections.
After the customer remediated duplicate employee IDs in AD, UNIFYBroker is still unable to correctly join and process links. The error message has changed to:
Synchronization job failed syncing 4322 changes on the 'Employee > AD User' link from the adapter to locker with the reason Join calculation for source entity 'e892faf3-5c17-4e9c-9be9-f9ee33cc68fe' cannot be completed due to an invalid connection state. Reason: Source entity has multiple connections.. Job ID: bf3c52ec-49a2-4655-8f00-360a6ffce78c Duration: 00:00:04.2503352
I'll attach the email thread with the customer that provides background to the next message.
Identifying previously denied entities in UNIFYBroker/Plus post-provisioning and synchronisation tasks
Entities that have been pushed onto $denySync in an link's pre-provisioning task may need to be excluded from certain operations in the synchronisation and post-provisioning tasks. For example, if an AD user has not been excluded from provisioning then an attempt to assign birthright AD groups will always fail, and should not be performed.
If would be helpful if there was some mechanism (e.g. a $denySync.ContainsEntity($Entity) method which returns $True if the entity has been .Push()ed previously) to allow detection of this situation.
The current workaround is to duplicate/copy the code from the pre-provisioning task which determines when to add the entity to $denySync into the post-provisioning and/or synchronisation task.
Joins to non-existant adapter objects created when outgoing baseline syncs fail to provision in the connector
I have a customer where connector entity create fails (due to external issue on the customer side) for a number of entities during link sync, and for each one I end up with a Join showing on the Locker but no corresponding adapter entity.
For example, for a baseline sync I see: Update entities 1690 to connector AD User reported 1690 entities saved, 3 failed
After this I look at locker joins: Showing 1 to 10 of 1,693 entries
But adapter joins says: Showing 1 to 10 of 1,690 entries
This causes problems on the next baseline sync, because even though the locker is already joined (to a non-existant adapter entity) another attempt to create the adapter/connect is still made but then this error appears:
Unify.Product.Plus.JoinExecutorTargetEntityAlreadyJoinedException: Source entity '2ac4395a-2cb7-4f6e-9d80-e6a6a38994b7' value matched to target entity 'f70abdcf-4097-4d41-84a6-b0703308f16f', however this target entity is already connected to another source entity. 'fb9d3fea-9b4a-4708-a0e1-e730551ef030'. Cannot proceed with join.
I thought we worked through this and already had a patch for this issue, but I cannot work out which ticket it was in.
Could you please investigate and see what the situation around this is?
Field mapping priority not respected when Baseline sync is run on a Link
My customer has two adapters contributing data to the same locker field via two links. I have set a priority sequence for the field, but when I run a Baseline sync on the link with the lower priority mapping the field in the locker is updated with the (wrong) value from that lower priority source. Running a Baseline Sync on the link with the higher priority mapping set the locker field back to the (right) value from the higher priority source. The most recent Baseline sync to run always wins, regardless of the priority setting.
Customer support service by UserEcho
