I am unsure of how my API should respond when it receives a PATCH request to add/update a SCIM User attribute when the User model does not support that.
Let's assume that my User model doesn't have a "title" attribute, but the identity provider (Azure AD) has a mapping for it. During provisioning, Azure sends a PATCH request to perform a SCIM add operation to set the "title" attribute. How should my API respond in this case?
I have looked through the SCIM Protocol Spec (RFC-7644) and SCIM Core Schema (RFC-7643), but the answer is not clear to me. There are three options that I can see as potentially valid:
scimType = "invalidPath"scimType = "noTarget"Section 3.12 of the Protocol Spec contains information on error handling, including the scimType definitions for 400 responses.
The description for invalidPath reads:
The "path" attribute was invalid or malformed (See Figure 7).
The description for noTarget reads:
The specified "path" did not yield an attribute or attribute value that could be operated on. This occurs when the specified "path" value contains a filter that yields no match.
noTarget seems very close to the correct response, but the second sentence (and other descriptions in the spec) make me think it's only for complex attribute types. invalidPath doesn't seem to be the best option because "title" is a valid attribute for User according to SCIM spec. My application just doesn't support it.
Update (08/28/2020): I decided to just ignore the attribute and return 200 if there are no other issues with the operation. Azure AD Provisioning will send the request, see a success, and then ignore it until there's a change. I was initially worried that Azure would continuously resend the update operation until the value appeared on the User, but that's not the case.
I still don't have an answer for what is in spec, but it works. There have been other operations where I feel like I returned the proper error according to spec, but Azure would repeatedly resend the bad request.
As you rightfully state, if there is a (misconfigured) mapping to an attribute that is unknown, then it is okay to silently ignore it. Returning an error would kick-in retries until the provisioning is aborted altogether. There is no enforcement, that the client double checks whether the requested change actually is manifested in the response. Spec states that 204 is okay as well.
Also we could be in the scenario, where the attribute does exist, but momentarily is readonly. Eventually, due to a changed object state, it might becomes writable. Returning that fact with an hardly reproducible error would cause unnecessary fixing attempts in the mapping.
Think of it as an End-User trying to be clever and modify some value in the payload, that the UI did not offer any option for to change. Just discard that.