Bugs
SCIM user cannot be retrieved immediately after creation, so their manager isn't set
Azure's SCIM implementation when creating a user who has a manager follows this approach:
1. Create the new SCIM user (without the manager reference)
2. Make sure the new user has been created
3. Update the new user's manager field
It seems the reason for this approach is because Azure wants to create all the users first, before it tries to add references to them via the manager field (which makes sense from a referential integrity perspective).
However, when using the UNIFYBroker SCIM gateway, step 2 is failing and Azure can't find the newly created user. Azure first tries to get the new user object by ID, and then by username lookup, but neither works. See the attached packet trace "SCIM User with manager creation.pcapng" for details. The connector/adapter entity created has the same entity ID that was returned to Azure (9a9978e0-6179-42b5-8218-2173d7b6c0e5 in the packet trace) and the username field set correctly (adrian.corston@unifysolutions.net).
A later attempt by Azure to look up that entity by username (package trace "SCIM User lookup.pcapng") is successful (that lookup was followed by a PATCH which failed, but that is due to a different issue so please ignore that part of the trace).
SCIM User with manager creation.pcapng
SCIM User lookup.pcapng
This github ticket has information about the Azure SCIM pattern for setting manager: https://github.com/MicrosoftDocs/azure-docs/issues/11784 (comment from asmalser-msft)
Customer support service by UserEcho
Hi Adrian
This is the expected behaviour. Broker takes time to process added entities, which may not have completed before AAD's confirmation search. As you observed, AAD tracks and retries incomplete operation for these kind of scenarios.
I've also encountered the PATCH issue, and I've implemented a fix that will be included in the patch for your other SCIM issue. In my experience this issue completely prevents all update operations from succeeding, however you've only mentioned it here in passing. Is there a work around or something for this that I've missed, or have you just not got to the point of creating a voice topic for it yet?
Thanks Beau. Yes, I have more tickets I haven't raised yet - only so many hours in the day :-)
I am using Azure's "Provision on Demand" feature while developing my configuration, rather than wait for 40 minutes between each of Azure's scheduled provisioining runs. What you're saying here means I will have to wait 40 minutes each time I want to try out a new configuation option, which is a significant development overhead since I typically do that many times while working out a new feature. Is it feasible to add a flag to the SCIM gateway to not direct it to delay and not return a value for the creation request until the connector object is available, in order to remove this burden from the development process?
Not really a viable option. This is just the way Broker works, and isn't exclusive to the SCIM gateway. Same behaviour could be observed with LDAP, as well. Also, I don't think AAD waits until the next scheduled provisioning to retry, but that's not something I've be able to confirm. Either way I'd recommend to keep using Provision on Demand during development.
Hi Beau, when testing creation of a new user via SCIM for a user who has a manager, the way UNIFYBroker works means that the manager doesn't get set during Provision on Demand. The only way to test that it works is to enable full Azure App provisioning and wait for the next cycle (up to 40 minutes). This is what I mean when I said that I have to wait 40 minutes when doing testing. Not a show-stopper but it does have the potential to impact a project delivery timeline. That said, once I have it working I will write it up as a design pattern and re-use the configuration - so this will only be something I have to do once.
At the moment I'm trying to connect a SCIM gateway directly to AD connectors for user and group provisioning. If I can't get it to work this way then my backup plan is to provision users and groups to placeholder connectors and use UNIFYBroker/Plus to push that data into the AD connectors via a locker.
Hi Adrian,
Just so I can understand - are you saying for any manager allocated to a new user, they're not getting set? In our testing, if the manager already exists in the solution (IE run in a different provision cycle) then they'll be set on the user. It only seemed to be if the manager didn't exist in the current cycle that it caused problems.
Just wanting to confirm the behaviour you're seeing so we can dig a bit further into it from our end.
Hi Matt,
The Microsoft/Azure pattern is to not set the manager on the new user creation. Once all the users have been created, it then does a second cycle where it checks to make sure the user has been created, and if so then goes ahead and sets the manager on that user. Because UNIFYBroker is telling Azure that the new user hasn't been created yet, Azure doesn't try to set the manager.
Hi Adrian,
I've added an item to our backlog for our next UNIFYBroker version (currently being worked on) to investigate whether there's any options to support what you're after. I can't promise anything at this stage given how the gateways work, but Beau and I will do some deep diving at some stage and see if there's anything we can come up with to assist for the next version.
Matt pointed out that a subsequent manual attempt to POD the newly created user will attempt to PATCH and add the manager, which is exactly what I want. Thank you Matt!