在PATCH请求中处理不受支持的SCIM属性

问题描述

我不确定我的API在收到PATCH请求以在用户模型不支持时添加/更新SCIM用户属性时应如何响应。

让我们假设我的用户模型没有“ title”属性，但是身份提供者（Azure AD）具有一个映射。在配置期间，Azure发送PATCH请求以执行SCIM添加操作以设置“标题”属性。在这种情况下，我的API应该如何响应？

我已经浏览了SCIM Protocol Spec (RFC-7644)和SCIM Core Schema (RFC-7643)，但是答案对我来说还不清楚。我认为三个选项可能有效：

1. 忽略该操作并返回200响应（假设没有其他问题）
2. 使用scimType = "invalidpath"返回400响应
3. 使用scimType = "noTarget"返回400响应

协议规范的

Section 3.12包含有关错误处理的信息，包括400个响应的scimType定义。

invalidpath的描述为：

“ path”属性无效或格式错误（请参见图7）。

noTarget的描述为：

指定的“路径”没有产生可以操作的属性或属性值。当指定的“路径”值包含不匹配的过滤器时，就会发生这种情况。

noTarget似乎非常接近正确的答案，但是第二句话（以及规范中的其他描述）使我认为这仅适用于复杂的属性类型。 invalidpath似乎不是最佳选择，因为根据SCIM规范，“标题”是User的有效属性。我的应用程序不支持它。

更新（2020年8月28日）： 我决定忽略该属性，如果操作没有其他问题，则返回200。 Azure AD Provisioning将发送请求，看到成功，然后忽略它，直到发生更改为止。最初，我担心Azure会继续重新发送更新操作，直到该值出现在User上，但事实并非如此。

对于规范中的内容，我仍然没有答案，但是它可行。还有其他一些操作，我觉得我根据规格返回了正确的错误，但是Azure会反复重新发送错误的请求。

解决方法

正如您正确指出的那样，如果存在（错误配置的）到未知属性的映射，那么可以静默忽略它。返回错误将立即重试，直到完全中止配置。没有强制执行，客户端会仔细检查请求的更改是否实际上在响应中得到体现。 Spec指出204也可以。

我们也可能处于该属性确实存在但暂时是只读的场景中。最终，由于对象状态更改，它可能变得可写。返回具有几乎无法重现的错误的事实将导致映射中不必要的修复尝试。

将其视为最终用户，试图变得聪明并修改有效负载中的某些值，因为UI没有提供任何更改选项。丢掉它。