azure - Microsoft Azure 是否滥用 SCIM RFC？ `emails[type eq "工作"].value eq "foo@example.com"`

Question

我们在实现 SCIM API 和让 Azure 在每种情况下都满意方面遇到了问题。Microsoft 试图为人们提供 configure how their active directory将映射到 SCIM 实现，并提供如下建议:

emails[type eq "work"].value

但是我们当前的 SCIM 实现很难支持这种过滤器表达式的混合。我们能够支持:

emails.value eq <a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4e2821210e2b362f233e222b602d2123" rel="noreferrer noopener nofollow">[email protected]</a>

我们能够提供支持

emails[type eq "work" and value eq "<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="f89e9797b89d80999588949dd69b9795" rel="noreferrer noopener nofollow">[email protected]</a>"]

但是我们很难支持[括号表达式]与.value表达式的混合

我的问题是，“Microsoft 是否正在做一些违反 RFC 的事情？”

显然还有其他类似的Issues reported to Jira .

here are some examples from the SCIM RFC .

我们目前正在使用scim2_filter_parser来帮助转换，但现在如果我们得到这个组合查询，我们就会举手。我也很好奇其他 SAAS 组织是如何处理这个问题的。我们只为每个用户存储一封电子邮件，因此我们实际上只关心您的“工作”电子邮件。 SAAS/SCIM API 提供商支持多种“类型”电子邮件的情况有多常见？

Answer 1

我是 Microsoft 的一名产品经理，与 SCIM 保持一致，是的，我们在这里错了。纠正这个问题和其他一些类似的问题已在我们的短期/中期计划中。不幸的是，直到最近一两年，这个问题才引起我们的注意(据我所知)。鉴于人们已经实现了对该模式的支持 5-6 年，并且可能不支持其他模式，例如 ?filter=emails[type eq "work"and value eq "[email protected] "]，更改此模式的路径比想象的要复杂得多首先出现。

现在，您的选择是支持该过滤器，即使 ABNF 不允许，或者不将电子邮件属性与 AAD/EID 的 SCIM 配置一起使用。

FWIW，这可能是用于过滤表达式的 ABNF 设计中的遗漏，因为子属性表示法可用于其他场景，例如 PATCH 请求中的路径值。这并没有改变今天不允许这样做的事实，但如果开发/发布新版本的 SCIM，IETF 的 SCIM 工作组可能会提议对此进行更改。对此过滤器结构的支持似乎并不是与其他地方的互操作性的重大变化，而只是打开了额外的过滤逻辑。

最终，我们仍然计划改变这一点 - 所以上面的段落实际上只是我自己的想法。