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

Question

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

假设我的 User 模型没有“title”属性，但身份提供者 (Azure AD) 有一个映射。在预配期间，Azure 发送 PATCH 请求以执行 SCIM 添加操作以设置“title”属性。在这种情况下，我的 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 的描述如下：

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

noTarget 的描述如下：

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

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

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

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

Answer 1

正如您所说的那样，如果（配置错误）映射到未知属性，则可以静默忽略它。返回错误将启动重试，直到配置完全中止。没有强制执行，客户端会仔细检查请求的更改是否实际显示在响应中。 Spec 声明 204 也可以。

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

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