Thanks for your patience here.
In short - I think what you wrote above is a reasonable interpretation of what should be expected here. This part of the SCIM spec feels a bit tricky no matter how you look at it, but there are certain parts of the SCIM spec (RFC7644 220.127.116.11) tied to the Patch Add operation that are relevant here:
- If the target location does not exist, the attribute and value are added.
- If the target location specifies an attribute that does not exist (has no value), the attribute is added with the new value.
When interpreting what those mean - you then end up trying to define "target location", which doesn't have a strict definition inside of any of RFCs 7642/43/44. This in turn may be where the trouble is - if "target location" is considered to be emails[type eq "work"].value - if the location does not exist, then the attribute(emails[type eq "work"]) is added, and the value (of the "value" sub-attribute) is added.
What Azure AD's SCIM client should do here is still being investigated, but any changes won't materialize for at least a few quarters. Regardless of whether the spec supports the way our client does this, there's a simpler and more widely compatible solution to achieve the same goal. For the time being, what Azure AD's SCIM client expects is a patch add on a filtered path - such as emails[type eq "work"].value - should add values to both the "type" (if no value of "emails" already exists with a type sub-value of "work") and the "value" sub-values.
Thank you! I look forward to and am still interested in understanding.
@Danny Zollner Do you have an answer to this?
Hello @DanP110 ,
We are running in the same issues. We have implemented a SCIM server based on the RTF specifications. But now our clients want to patch attributes using filter expressions. Based on the specification our server rejects Add operations if the filter does not yield any results. Unfortunately this does not seem like how the AD SCIM client is working. It looks like it wants the SCIM server to create entries, if the filter does not match. We are very hesitant to patch our SCIM server in order to work that way, because it will break other clients who only want to update attributes if the filter expression does match.
We moved forward by implementing specific functionality behind a feature flag to deal with what appears to be a deviation from the spec. That code counts on the filter expression to extract an actual type value as I originally mentioned. It's almost like Azure is treating the full expression like it was a simple attribute name. After dealing with multiple other clients, we have ended up with a few feature flags like this (e.g. there is a flag to control if a POST to re-create an existing user results in a 409 conflict or gets treated like it was an UPDATE; spec says 409, client wants UPDATE).
Sign in to comment