Bugs
SCIM gateway attribute update comes through as XML document
An update from Azure via the SCIM gateway is being passed through to the adapter as a large XML document, as shown in this UNIFYBroker PowerShell log entry in a reverse adapter transform:
Before this SCIM update was received, the JobTitle field in the adapter for this user was NULL. After the export update was received and processed the field in the adapter contained the XML document content. Here is what the Azure POD showed:
According to Azure, it doesn't appear to be updating the title SCIM attribute (which ismapped to the JobTitle adapter field) at all, but nevertheless UNIFYBroker is populating it with XML document content by the time it gets to the adapter reverse transform.
Here's the adapter reverse transform (which doesn't do anything with JobTitle) showing the logging code:
Customer support service by UserEcho
Hi Adrian,
How does Azure AD report the field hasn't been updated? I've noticed in the past that that XML contains timestamp values which are always set to the current time, so that field will always be updated when provisioning is run as there will always be a difference between the current value according to Broker and the current value according to AAD. Could this be related to the issue you're having here?
The last POD screen snapshot suggests to me that Azure is only updating the 'preferredLanguage' attribute, because that's the only attribute shown. Unfortunately I have no way to confirm what's really going on at the SCIM protocol level sorry :(
If you want to debug something in place then I can trigger SCIM PODs to facilitate this. The service isn't live currently.
We can't really control what Azure shows, but I would imagine it'd report an error if it detected that something expected didn't happen. I doesn't seem like anything out of the ordinary occurred, at least as far as Broker is concerned. Have you noticed any problems with subsequent provisions?
Yes, it keeps setting the JobTitle attribute to the XML document, every time I run a POD.
I've had to remove that attribute flow for now, because the customer wants to do UAT. So they'll soon report that the flow is missing.
Is there some way it can be debugged?
That's the issue I described in my first comment. No way to prevent that, as the XML string in the update will always be different to the XML string in Broker.
The user's Job title in Azure is blank. The current adapter field value in UNIFYBroker is NULL. UNIFYBroker is passing the adapter an XML document on the update entity call. It should be passing an empty string instead.
This isn't related to the role issue with the XML document on that one - that's a different and unrelated voice ticket.
Strange. That XML definitely coming from AAD, though. There's nothing in Broker that would generate that, and SCIM is JSON based, not XML. We don't have the ability to perform network traces in Connect instances yet, you'd have to setup a debug environment in a VM if you want to do that and confirm.
Seems like it could be an issue with the provisioning mapping in AAD. Possibly not actually updated despite saying it has?
Hi Beau,
Unfortunately I don't have time to set up a UNIFYBroker environment with SCIM endpoint to debug this at the moment. I could repoint the customer's SCIM endpoint to an existing one of yours if you need me to - let me know and I'll provide the Azure domain name for authorisation.
Hey Adrian,
If your lab isn't available at the moment then that's all good - we'll see if we can narrow it down a few other ways.
Are you seeing the same behaviour in another environment (dev/test)? If you point the Azure AD jobTitle attribute to a different SCIM attribute, does the same value come through to that new attribute? What about pointing a different Azure AD attribute through to the title SCIM attribute?
The blob coming through looks like provisioning detail for the whole app, which suggests to me something funny inside Azure AD and that value is ending up with the contents of the document.
I also note the Azure AD UI screenshots show the SCIM attributes as "customappsso" attributes. Is this app an older one or has it been downgraded from the SCIM job to a customappsso job? Or is that just the AAD UI not showing correct information?
I finally worked out what was going on here. At some stage I mapped the role through to the target field on the adapter entity, and the XML document value was stored into it. Then I changed the mappings to source the value from jobTitle instead. However, on my test user in Azure the jobTitle is null. When jobTitle is null, Azure doesn't synchronise a blank/null value to the target system via SCIM, even if the target has a value on that field currently. So UNIFYBroker was simply retaining the XML document value that was set by the previous mapping, and Azure was never clearing it out. Once I put a value into jobTitle on the source user object, it updated just fine.
I think not clearing target values in this case is a clear fail by Azure's SCIM implementation, so I'll open a ticket with MS instead. This one can be marked as 'not a bug' and closed.
Also, I have no idea about the customappsso thing, sorry.