1

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 foo@example.com

And we are able to support

emails[type eq "work" and value eq "foo@example.com"]

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 Examples from 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?

Matt
  • 5,028
  • 2
  • 28
  • 55

1 Answers1

2

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 "x@y.com"], 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.

Zollnerd
  • 725
  • 4
  • 5