我们在实现SCIM API和让Azure在每个场景中都满意方面遇到了问题。微软试图为人们提供配置他们的活动目录如何Map到SCIM实现的建议，如：
emails[type eq "work"].value字符串
但是我们当前的SCIM实现难以支持过滤器表达式的这种混合。我们能够支持：
emails.value eq foo@example.com型
我们能够支持
emails[type eq "work" and value eq "foo@example.com"]型
但是我们很难支持[bracket expression] with the .value expression的混合
我的问题是，“微软在这里做了一些违背RFC的事情吗？“
显然还有其他类似的Issues reported to Jira。
here are some examples from the SCIM RFC
。
我们目前正在使用scim2_filter_parser来帮助转换，但是现在如果我们得到这个组合查询，我们就放弃了。我也很好奇其他SAAS组织是如何处理这一点的。我们只为每个用户存储一封电子邮件，因此我们只关心您的“工作”电子邮件。SAAS/SCIM API提供商支持多种“类型”的电子邮件有多常见？
1条答案
按热度按时间cedebl8k1#
我是微软的一名PM，与SCIM保持一致，是的，我们在这里是不正确的。纠正这个问题和其他一些类似的问题是在我们的短期/中期计划。不幸的是，直到最近一两年才引起我们的注意（据我所知）。考虑到5-6年来人们实现了对这种模式的支持，并且可能不支持其他模式，比如？filter=emails[type eq“work”and value eq“x@y.com“]，更改此属性的路径比它最初出现时要复杂得多。
现在，您的选择是支持该过滤器，即使ABNF不允许它，或者不使用AAD/EID的SCIM配置的电子邮件属性。
FWIW，这可能是用于过滤表达式的ABNF设计中的一个遗漏，因为子属性符号可用于其他场景，如PATCH请求中的路径值。这并不能改变今天不允许这样做的事实，但如果新版本的SCIM被开发/发布，IETF的SCIM工作组也可能会提出这样的改变。对这种过滤器结构的支持似乎并没有对其他地方的互操作性造成重大改变，只是打开了额外的过滤逻辑。
在一天结束的时候，我们仍然计划改变这一点，虽然-所以上面的段落真的只是我自己的想法。