Ideas
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
Answer
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?
Hi Matt, no.
The problem I have is that when the user that has been deleted from Azure but left behind in UNIFYBroker is re-assigned to the application it causes the behaviour of ticket https://voice.unifysolutions.net/en/communities/6/topics/4314-error-during-scim-operation-systeminvalidoperationexception-sequence-contains-more-than-one-element.
Data mislignment (e.g. the presence of UNIFYBroker entities and Azure application role assignments out of sync - one existing and the other not) appears to be a contributing cause for that issue, and it's also confusing for anyone working with the solution.
Based on discussion of a similar (but different) use case in https://docs.microsoft.com/en-us/answers/questions/6670/azure-ad-scim-not-sending-delete-requests.html I am wondering if users removed from applications are disabled (i.e. "active" flag set False) for some time period after the user is removed from the application assignment.
This link provides more insight which supports my theory: https://stackoverflow.com/questions/68946014/how-are-azure-issoftdelete-false-true-values-determined
I think that probably adequately explains Azure's behaviour - it keeps the recently-unassigned users in SCIM, but sets the IsSoftDeleted flag True. With that in mind, the thing I need fixed is the error the UNIFYBroker generates when the user is re-assigned (https://voice.unifysolutions.net/en/communities/6/topics/4314-error-during-scim-operation-systeminvalidoperationexception-sequence-contains-more-than-one-element).
Customer support service by UserEcho
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?