We are having issues implementing our SCIM API and making Azure happy in every scenario. Microsoft tries to provide for folks to configure how their active directory will map to the SCIM implementation with suggestions like:
emails[type eq "work"].value
but our current SCIM implementation struggles to support this mixture of filter expressions. We are able to support:
emails.value eq [email protected]
And we are able to support
emails[type eq "work" and value eq "[email protected]"]
But we struggle to support this mixture of [bracket expression] with the .value expression
My question is, "Is Microsoft doing something that goes against the RFC here?"
There are clearly others similar Issues reported to Jira.
here are some examples from the SCIM RFC
.
We are currently using scim2_filter_parser to help with the conversion, but right now we throw up our hands if we get this combined query. I'm also curious how other SAAS organizations are handling this. We store only one email per User so we really only care about your "work" email. How common is it for SAAS/SCIM API providers to support multiple "types" of email?
I'm a PM at Microsoft aligned to SCIM, and yes, we're incorrect here. Correcting this and some other similar issues is in our short/mid-term plans. Unfortunately, this wasn't raised to our attention (as far as I know) until the last year or two. Given 5-6 years of folks implementing support for this pattern and possibly not supporting other patterns like ?filter=emails[type eq "work" and value eq "[email protected]"], the path to changing this is more complicated than it may first appear.
Right now, your options are to support that filter even though it isn't allowed by the ABNF, or to not use the emails attribute with AAD/EID's SCIM provisioning.
FWIW, this may have been an omission in the design of the ABNF for filtering expressions, since the sub-attribute notation is usable in other scenarios like the path value in a PATCH request. That doesn't change the fact that this is not allowed today, but it's also something that may be proposed as a change within the IETF's SCIM working group should a new version of SCIM ever be worked on/released. Support for this filter structure doesn't appear to be a breaking change with interoperability elsewhere, and just opens up additional filtering logic.
At the end of the day, we're still planning on changing this, though - so the above paragraph is really just my own thoughts.