Forum Discussion
Azure AD SCIM Validator is in General Availability (GA) Status
alexjones You are right. We have an issue with the 'phoneNumber' 'primary' attribute which should be sent as a Boolean, but SCIM Validator sends it as string, ignoring the schema. We have this captured in our backlog of issues to be addressed this quarter (ending in September)
Hi Owino,
I just have a couple of questions on some of the PATCH operations in the SCIM validator.
Should the following PATCH operation be allowed?
{
"op": "replace",
"path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager",
"value": ""
}
This looks like it should be a 'remove' operation to me. We're currently running into an issue around the value being empty due to validation in our implementation for 'replace' operations.
Should the following mapping exist in the defaults?
roles[primary eq "True"].display
Primary is a boolean attribute and is expected to be a string in the filter here. In addition to this, the initial create request doesn't contain any roles. This means when that even when the filter does include a boolean and the filter is ran, there is no role for primary and so the value for the 'type' attribute cannot be replaced.
{
"op": "replace",
"path": "roles[primary eq true].type",
"value": "I6T3MZAC1HXV"
}
What's the intention of the following PATCH operation?
{
"op": "add",
"path": "emails[type eq \"work\"].value",
"value": "email address removed for privacy reasons"
}
In the SCIM validator this example has the same issue as the previous, where there are no emails in the initial create request and so the filter fails to find an email to add a 'value' to. I wanted to double check that the intention of the request wasn't to add an email like the following
{
"type": "work",
"value": "email address removed for privacy reasons"
}
I understand there are a few issues here, any help will be greatly appreciated! Thanks!