2

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

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

我查看了SCIM 协议规范 (RFC-7644)和SCIM 核心架构 (RFC-7643)，但我并不清楚答案。我认为三个选项可能有效：

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

协议规范的第 3.12 节包含有关错误处理的信息，包括scimType400 响应的定义。

描述invalidPath如下：

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

描述noTarget如下：

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

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

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

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

4

1 回答 1

1

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

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

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

于 2020-09-24T22:45:03.167 回答