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.
Support for multi-valued attribute in the SCIM gateway
I am looking into getting multi-role support for Azure App Provisioning with UNIFYBroker following the process described on this page: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes#provisioning-a-role-to-a-scim-app
Specifically, I’m using the ‘AppRoleAssignmentsComplex’ case, because some customers need the multi-role scenario (i.e. users can be assigned to multiple roles for the same app).
To make this work Azure needs to use a SCIM attribute that supports multi-values (see ‘Example output’ for a non-normative example).
Are there any multi-valued attributes in the current UNIFYBroker SCIM gateway implementation that I can use for this?
If not then is it possible to implement one using the current SCIM library, or will it only be possible once the SCIM gateway is ported across to a different DLL?
CSV connector fails all add entities during data load if the file doesn't exist
I'm doing data load in a new environment and an export CSV didn't exist before I ran Add Entities to populate it. Since the file didn't exist the connector is failing the entity adds and the log file is now filling with one error for each entity, which has made the system unusable for over 5 minutes. If I had more like 100,000 records to write out this could delay the data load activity for an hour or more.
While not a show-stopper (I've now created a CSV file with headers and no data and re-run the Add Entities operation) it's annoying and I don't see why the file can't simply be created if it doesn't exist.
Duplicate Adapter IDs in extensibility clear the extensibility file on failed service start
Hello Team,
I understand editing the service extensibility config directly is not supported/recommend, and therefor this issue shouldn't be expected to impact any environments under normal circumstances. However I found some interesting behaviour that occurs when an AdapterConfiguration object in the Unify.Product.IdentityBroker.AdapterEnginePlugInKey.extensibility.config.xml file is given a duplicate "AdapterId".
When attempting to start the service with an incorrect configuration like this, the service fails to start which is expected, however the entire Unify.Product.IdentityBroker.AdapterEnginePlugInKey.extensibility.config.xml file is also cleared and saved in the process. Clearing any other configuration that may be there. I'm unsure if this is intended behaviour, but figured I would log this here anyway for your consideration so the service would simply fail and not save over the configuration.
UNIFYBroker version 5.3.1
Thanks
Latest patches for UNIFYBroker/Plus
Hi Matt/Beau,
I am currently installing UNIFYBroker/Plus with a UNIFYConnect-style configuration for a customer. The OOTB connectors are Chris21 and AD, and there is also an existing PowerShell connector for “PeopleStreme” (a REST API-based recruitment system) that is being extended and a new “Mercury HR” CSV file import being added.
Could you please send me all the UNIFYBroker/Plus patches and files (both service and web) that I will need to run the latest version of UNIFYBroker/Plus successfully in this environment? There has been a lot of work done since the last official release on Voice. It would be great if I could patch this environment up to the same base level as the UNIFYConnect environments.
Thanks.
SCIM gateway reports 'No mapping for field 'urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber'
I have a SCIM gateway configured in UNIFYConnect and the following error appears every time a SCIM request is received:
There is a mapping for the employeeNumber field, as evidenced here:
I tried recycling, and then deleting and recreating the gateway from scratch but it continues to give me the same outcome.
The UNIFYConnect external address for the gateway is "https://unifyconnect-scim-dev.unifysolutions.net/CUSTOMERNAME-dev-B2BAD/"
How can I stop this error from appearing and get my config to work correctly?
Disable (delete) SCIM operation errors in UNIFYBroker SCIM gateway
I removed a user's application assignment in Azure and it initated a disable (i.e. delete user profile) SCIM operation and reported a successful outcome:
However, the user profile object remained present in UNIFYBroker:
According to the UNIFYBroker logs the request came through as an entity update (I know this from the PowerShell debugging tracewrites shown):
20220428,13:07:42,UNIFYBroker,Logging,Information,Reverse Transform extracted ROLE=[NONE],Normal
20220428,13:07:42,UNIFYBroker,Logging,Information,"[EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXXXX.onmicrosoft.com] [TicketingID, XXXXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:42,UNIFYBroker,Connector,Information,"Request to update entity to connector.
Request to update entities [Count:1] to connector Ticketed Application Provisioning.",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,GIEBP(Application),Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,"PV=(XXXXXXXX) for [EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXXXXX.onmicrosoft.com] [TicketingID, Marketo.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,"Saving [XXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [EmployeeGuid, 14de44ec-2322-4c75-b745-cb873341f8e4] [Application, XXXXXXX] [Active, False] [UserPrincipalName, admin@unifyXXXXXX.onmicrosoft.com] [TicketingID, XXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4] [Role, NONE] [EmployeeName, David Parsonson] [0799C19A00044B368A7D06D9AE23CC07, c36f2c4a-4eb6-46ac-a69c-9565ec327e9e]",Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update: init Lines=@{Application=XXXXXXX; Active=True; EmployeeId=; EmployeeName=David Parsonson; Role=Admin; UserPrincipalName=admin@unifyXXXXXXXX.onmicrosoft.com; TicketingID=XXXXXXX.14de44ec-2322-4c75-b745-cb873341f8e4; EmployeeGuid=14de44ec-2322-4c75-b745-cb873341f8e4} @ 1,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update: after Lines=@{Application=XXXXXXXX; Active=False; EmployeeId=; EmployeeName=David Parsonson; Role=NONE; UserPrincipalName=admin@unifyXXXXXXX.onmicrosoft.com; TicketingID=Marketo.14de44ec-2322-4c75-b745-cb873341f8e4; EmployeeGuid=14de44ec-2322-4c75-b745-cb873341f8e4} @ 1,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,update done,Normal
20220428,13:07:45,UNIFYBroker,Logging,Information,Updated 1 entities in C:\CSV\XXXXXXXX-Users.csv,Normal
20220428,13:07:45,UNIFYBroker,Connector,Information,"Update entities to connector completed.
Update entities 1 to connector Ticketed Application Provisioning reported 1 entities saved, 0 failed. Duration: 00:00:02.9484342",Normal
The UNIFYBroker entity for the user should have been deleted rather than updated. It looks like UNIFYBroker has missed the "Action: disable" part of the SCIM request from Azure, which is the only indication I can see that the request was to disable/delete the user, rather than update it.
Can you please check that UNIFYBroker work with SCIM disable requests from Azure correctly?
This is high priority for me as I have been asked to deliver SCIM app provisioning functionality (including disable) for the customer to UAT by early next week.
Thanks
Hi Adrian,
According to the Microsoft documentation, the "Disable" operation is a patch (update) operation on the 'active' schema field: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#disable-user
Based on this, triggering an update on the user is the correct behaviour in this scenario. The delete operation is a separate SCIM action (HTTP DELETE) so to delete the entity record,, that operation would need to be triggered.
Is there some documentation or design pattern you can share, where you're seeing that removing a users application assignment should remove the entity in the consuming SCIM application?
Error during SCIM operation: System.InvalidOperationException: Sequence contains more than one element
I am seeing the above error *sometimes* when attempting to update a user via SCIM.
In every case of the error that I've seen SCIM has been trying to update a single field (Role) which is mapped from Azure's large "appRoleAssignments" XML field value, but I don't actually know if that's relevant or coincidental.
The full stack trace is:
20220428,11:53:00,UNIFYBroker,Logging,Information,Healthcheck,Normal
20220428,11:54:00,UNIFYBroker,Logging,Information,Healthcheck,Normal
20220428,11:54:05,UNIFYBroker,SCIMGateway,Error,"Error during SCIM operation: System.InvalidOperationException: Sequence contains more than one element
at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
at Unify.Product.IdentityBroker.SCIMProvider.Patch(IAdapterEntity adapterEntity, PatchRequest2 patch, ISCIMGatewayMapping mappings, IValueAdapter`2 valueAdapter, IEntitySchema schema)
at Unify.Product.IdentityBroker.SCIMProvider.d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderBase.d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderAdapterTemplate`1.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ControllerTemplate`1.d__5.MoveNext()",Normal
20220428,11:55:00,UNIFYBroker,Logging,Information,Healthcheck,Normal
Here's the Azure provision on demand output that corresponds to the error:
I can't work out why this happens for some user updates, but others go through just fine. Since I can't packet trace the SCIM protocol in UNIFYConnect environment my ability to debug this is limited, and unfortunately right now I don't really have time to set up a non-UNIFYConnect test environment to debug what's going on.
The backing connector for the SCIM gateway is a PowerShell one, but the error appears to be occurring before it's even called.
I saw https://voice.unifysolutions.net/en/communities/6/topics/3913-sequence-contains-more-than-one-element for the same error, but I am running the latest of everything so the advice on that ticket (upgrade) didn't help.
Do you have any hints what might be going on to result in that error message?
SCIM gateway doesn't appear to support update with multiple changing attributes
I put through an update from Azure via SCIM which had two attributes changing at the same time, and the following error appeared in the UNIFYBroker log:
20220422,05:36:27,UNIFYBroker,SCIMGateway,Error,"Error during SCIM operation: System.InvalidOperationException: Sequence contains more than one element
at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
at Unify.Product.IdentityBroker.SCIMProvider.Patch(IAdapterEntity adapterEntity, PatchRequest2 patch, ISCIMGatewayMapping mappings, IValueAdapter`2 valueAdapter, IEntitySchema schema)
at Unify.Product.IdentityBroker.SCIMProvider.d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderBase.d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ProviderAdapterTemplate`1.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SystemForCrossDomainIdentityManagement.ControllerTemplate`1.d__5.MoveNext()",Normal
Here is the corresponding update from the Azure side:
As a possible complication for this ticket, the user involved previously didn't have a value for their employeeNumber field (which is a required/key field of the underlying connector) and that caused this error:
20220422,05:34:08,UNIFYBroker,An exception has occured in the AdapterEntityChangeDetectorCollator. Please see the exception for details,Error,"Npgsql:
System.InvalidOperationException: Parameter 'key1value0' must have its value set
at Npgsql.NpgsqlParameter.ResolveHandler(ConnectorTypeMapper typeMapper)
at Npgsql.NpgsqlParameter.Bind(ConnectorTypeMapper typeMapper)
at Npgsql.NpgsqlCommand.ValidateParameters()
at Npgsql.NpgsqlCommand.d__100.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Npgsql.NpgsqlCommand.d__92.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Npgsql.NpgsqlCommand.ExecuteNonQuery()
at Unify.Product.IdentityBroker.MultiKeyValueQueryExecutor`2.PopulateTempTable(NpgsqlConnection connection, NpgsqlTransaction transaction, IDictionary`2 tempKeyLookup, ValueToObjectAdapter adapter, IEnumerable`1 multiKeyValues, String tempTableName)
at Unify.Product.IdentityBroker.MultiKeyValueQueryExecutor`2.Execute(NpgsqlConnection connection, ValueToObjectAdapter adapter, Guid partitionId, IEnumerable`1 multiKeyValues, String tempTableName, String entityValueFieldName, String entityTableName, String partitionIdName, Func`2 readData)
at Unify.Product.IdentityBroker.KnownEntityPartitionPostgreSqlUpdatableContextBase`3.GetEntities(Guid partitionId, IEnumerable`1 keys)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.<>c__DisplayClass1_0.b__0(MultiKeyValue`1[] multiKeyValues)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.ConvertConnectorEntities(IEnumerable`1 connectorEntities, IMultiKey`1 schemaKey, Func`2 retrieveEntities, Guid connectorId, IEnumerable`1 wellKnownEntities)
at Unify.Product.IdentityBroker.EntityRepositoryExtensions.ConvertConnectorEntities(IEnumerable`1 connectorEntities, IMultiKey`1 schemaKey, IKnownEntityContextBase`3 context, Guid connectorId, IEnumerable`1 wellKnownEntities)
at Unify.Product.IdentityBroker.EntityChangeDetector.ProcessConnectorChangedEntities(Guid connectorId, IEnumerable`1 connectorEntities, IEnumerable`1 wellKnownItems)
at Unify.Product.IdentityBroker.AdapterEntityChangeDetectorCollator.DetectChanges(KeyValuePair`2 connectorEntities)
at Unify.Framework.Visitor.<>c__DisplayClass0_0`1.b__0(T item, Int32 index)
at Unify.Framework.Visitor.Visit[T](IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Product.IdentityBroker.AdapterEntityChangeDetectorCollator.Run()
at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state)",Normal
Could you please investigate and fix the update error, and also consider improving the behaviour when a connector's required field is missing in a SCIM update?
For the purposes of my demo next week I can make sure this 'bad data' doesn't occur, and so the only dependency for this is SIT/UAT meaning that it's a medium priority.
SCIM user update not working in UNIFYConnect
I have a SCIM gateway configured in UNIFYConnect and Azure is able to use it to Add users just fine, but when it attempts an update this error is shown:
There's nothing written into the UNIFYBroker log when this happens.
Could you please investigate and advise how to make updates work?
Segment order in adapter multi-segment DN appears to be random
The strangest thing ever... For this adapter:
When I generate changes to update the DNs (used to be DN=@IdBID), I see DNs assigned with different segment orders like this:
The two digit CN is DepartmentID. The date CN is StartDate. The four digit CN is PositionID. The three letter CN is LocationID. The six digit CN is EmployeeID.
I tried clearing precalculated entities and re-running Generate Changes, but the same thing happens with the newly generated entities - the segments are always in the same (wrong) order for each entity.
This is happening in a non-Production environment, and the DN segment order for each entity appears to be persistent, so this is a very minor (but very strange) issue.
Hi Adrian,
The order should be consistent for the values provided. The order of the components only appears random for your implementation because you're using the same AttributeType identifier for your RDN sequence.
When the DN is built for an object, MultiPart components are first ordered by the AttributeType (CN, OU, UID etc) and then by the AttributeValue. In your case this means only the value is being taken into account because the type is the same for all parts of the Multi-part RDN.
In line with the LDAP RFC's (2253, 4514) a multi part RDN is not required to be in any particular order. While I'm not sure on the exact specifics of why we don't respect the order provided in the template, I suspect it relates to comparing DNs and allowing a consistent string representation.
If it's causing a problem I can investigate options for fixing or allowing a fixed order but would need to dig further into the implications.
Customer support service by UserEcho