We have a SCIM api running on production and we are running into problems with a Group PUT.
I have scanned the official SCIM spec, but I am not able to find an answer for this-what should happen when a Group PUT is called with a payload that has members: [...]
?
To be absolutely exact, if we receive a PUT with body like this:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"externalId": "8a06f2c2-aaaa-401b-b2b6-f54e5dac6f34",
"id": "7447",
"displayName": "Whatever",
"members": [
{
"value": "322257"
}
],
"meta": {
"resourceType": "Group"
}
Since this is a PUT we remove all members from that group and then add user 322257
to the group in a single DB transaction. Is this correct? PUT should replace all the SCIM attributes, so I would hope it is, but from what Azure cloud SCIM calls to our side it might seem like maybe we should not remove members here? Maybe we should keep the current members and just add the user 322257
?
Your interpretation is correct - the PUT request you provided should remove all group members and add only 322257 as a member. While the SCIM RFC mandates that you need to support PUT, in practice only POST + PATCH should be used for create/update, respectively.
You mentioned:
but from what Azure cloud SCIM calls to our side it might seem like maybe we should not remove members here?
The only way that Azure AD's SCIM service will issue PUT calls is if an application in the gallery with provisioning enabled has been configured to use PUT rather than PATCH. At this point in time any new provisioning integrations built for Azure AD require PATCH support for groups, and will never see PUT used. If you have an application that is still configured to use PUT on groups, that application should be updated from Microsoft's side to update that behavior, assuming the SCIM implementation on the other side supports PATCH on groups.