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.
PowerShell connector operation timeout
Add a feature to allow a timeout to be specified for a PowerShell connector operation (Import All, etc). When the timeout expires, forcibly kill the PowerShell operation and log an error.
This came up because a connector hung for ten days in a UNIFYConnect environment until I noticed. All of the other connectors in the same connector exclusion group were blocked from running as well. I suggest a default timeout of one hour for most operations and 10 minutes for Import Changes.
Add support for non-CSV connector types to the Test Harness plugin
Add support for non-CSV connector types to the Test Harness plugin.
This would help address problems relating to multivalued fields with commas in values.
Entity not updating after Foreign Multivalue Group relationship connector entity change
Adapter "AD Groups" has a FMG transform to connector "AD Entitlement Control Groups". When an existing entity in that connector updated (to add a second value to the "member" multivalued attribute) the FMG did not re-evaluate on the adapter. Running an Import All on AD Entitlement Control Groups did not update the AD Group adapter entity, and neither did running an Import All on the AD Groups adapter's base connector. The FMG field was only updated when I ran Generate Changes on the AD Groups adapter directly.
Access to source entity fields for target entities returned by CheckFieldUniqueness
When using the CheckFieldUniqueness component to ensure target entity field uniqueness I would like to use source entity field values in order to calculate candidate values for the unique field. I'm only aware of a way to access target entity field values.
Is there a way to access the source entities for a target entity in this scenario?
Otherwise, please change this ticket to an Idea to have the ability to do so.
I see. You could just mapping the required values to to fields on the target entities, but assuming you don't want to do that you should process the $joinedEntities collection into a HashTable keyed on the target entities. For example:
$entityMap = @{};
foreach ($joinedEntity in $joinedEntities)
{
$entityMap[$joinedEntity.TargetEntity] = $joinedEntity.SourceEntity;
}
You'll then be able to use the target entities returned by CheckFieldUniqueness to lookup the corresponding source entity efficiently.
Time Offset Flag description in UNIFYBroker doesn't match the implementation or the voice documentation
On the Edit Timeoffset Flag page in the UNIFYBroker UI, the description says:
In particular, "The target value is populated based on whether the current time is less than, equal to or greater than the offset value".
The Voice documentation (https://voice.unifysolutions.net/en/knowledge-bases/7/articles/2888-time-offset-flag-transformation) says:
An actual configuration appears like this in the UI:
When this transform was evaluated on 15/12/2020 for a value of StartDate="03/Feb/2020" the value to which PreStart was set was "Yes".
This matches the UI configuration, and the Voice documentation (i.e. source time compared to NOW - with the source time offset implied). However, it does not match the description in the "Edit Timeoffset Flag" UI (i.e. NOW compared to the offset value - with "offset value" presumably meaning "source time plus offset"). The "Edit Timeoffset Flag" UI description is reversed compared to those others and therefore misleading.
Allow $logger component to specify module and submodule fields
There is no documented way to set the third and fourth fields (which I will call 'module' and 'submodule') of each UNIFYBroker log entry when calling the $logger component. It would be nice to be able to set them to more informative values, rather than always having them as 'UNIFYBroker' and 'PowerShellTask' respectively.
Hi Adrian,
The $logger component is designed to be a simple wrapper around the logging mechanism. For more complex log messages, use the $messageService variable.
There's some extension methods provided for the next level of logging. You can find more information on those here:
Class NotificationEnumerableExtensions (unifysolutions.net)
Otherwise, you can use the underlying NotificationMessageService to notify listeners of a particular message. In this case, the product loggers will be listening on ILogEntryNotification: Class LogEntryNotification (unifysolutions.net)
The tricky thing with crafting one of these will be building the branding object, (for a BrandedLogEntry). Technically this would allow you to change both the 'module' and 'submodule' components.
For ease of use, i'd recommend just using the NotificationEnumerableExtensions to log - which still use the underlying product for the third field but allow you to define the fourth field.
As a side note, for some reason the $messageService variable isn't actually hooked up for the Plus components, but is hooked up for the Powershell connector and transformations.
Next run times don't look right for newly added connector schedules
It's ~9:30am and I just added and enabled an Import All and Import Changes schedule to a connector. The Import All I set to run at 12:55:57am, and the Import Changes every 1 minute. The following appeared, which doesn't look right - 1am isn't an hour away, and one minute is not 10 hours away:
Hi Adrian,
The scheduled times are displayed in the local time of the machine. In this case, the containers are running on UTC. So with the UTC time (at time of screenshot) being 11pm on 30 November, that looks accurate.
Re-order Connectors and Adapters
In UNIFYBroker we could edit the connector and adapter extensibility files to re-order the connectors and adapters in the web UI. Could you please add a facility to do this in UNIFYConnect?
Join with Sliding Window with Most Relevant doesn't match record with NULL end date
UNIFYBroker v5.3.2 with Chris21.
Chris21 Person adapter is configured with a Join transformation to a Chris21 placement connector with a Sliding Window and type Relevant. A placement with a start date in the past and a NULL end date is not being selected (a NULL end date means ongoing placement, with no scheduled end date). Instead, the most recent placement with a non-NULL end date is selected.
Here is the placement data:
Here is the configuration:
The transformed adapter data shows an incorrect posstart and posend (and all other selected attributes):
This problem did not occur in Identity Broker v4.
It may also be relevant to note that the 'First' or 'Priority Selection' radio box does not appear for the Relevant type. It used to appear for this transform and type in Identity Broker v4.
Hi Beau, sorry I thought I'd already responded to this. The problem was just a handful of records and Generate Changes cleared it. Please close this ticket.
REST API endpoint for external Azure Access Request call-ins
In this morning's MS Identity Advisors session MS provided a clear indication that they are planning to move towards a call-out model for on-demand Access Request integration with external systems. To get ahead of the curve on this, we could look at offering an extensible REST API endpoint in UNIFYBroker.
Typical usage would be:
Azure sends UNIFYBroker a request for user "bobsmith" asking UNIFYBroker for a certain attribute for that user (e.g. department number) or asking UNIFYBroker to provide an answer to a question (such as "is this user allowed to get access to resource X at the moment?") UNIFYBroker responds and Azure uses that information to approve or deny an in-flight Access Request.
My suggested solution is that the request for user "bobsmith" (and/or "resource X") would map to a adapter record lookup, and the "answer" UNIFYBroker gives back would be the value of one or more fields for that matching record.
Hi Adrian
Since v5.2, Broker has included the OData gateway, which allows adapter entities to be queried via an OData REST API, which would cover the use case in your example. That said, since it's introduction I don't believe it's seen much, if any, real usage so may not fully support the types of request and filtering features that would be expected of it. Improving the OData gateway is definitely something we're interested in for future releases, so if you have the chance to try it out your feedback would be appreciated.
Also introduced in v5.2, the SCIM gateway provides a REST API conforming to the SCIM 2 specification, a standardized data schema for transmitting identity information via JSON payloads. The primary usage of this gateway thus far has been to connect Broker with Azure AD, which operates as a SCIM client to pull and push standardized users and groups from Broker. I mention it because it does support search and filtering features that would cover your example use case, however the rigid data structure it provides may be too limiting for non-SCIM-specific scenarios.
Customer support service by UserEcho
