Forum Discussion

owinoakelo's avatar
owinoakelo
Icon for Microsoft rankMicrosoft
Sep 26, 2022

Azure AD SCIM Validator is in General Availability (GA) Status

You can now validate the compatibility of your SCIM provisioning endpoint and Azure AD code base using our Azure AD SCIM Validator. This tool can be used by ISVs who want to build SCIM compatible ser...
Provisioning
PatM_Cerberus's avatar
PatM_Cerberus
Copper Contributor

Looks like there was recently a big update on the Validator. The "Discover Schema" now sets the correct type (string/boolean). Thank you!

However, now we're seeing a new complication. It appears the Validator is trying to add new entries using replace with a value selection filter (valuePath). This was discussed in 708183: SCIM PATCH of Complex Multi-Valued Attribute Includes Filter and Sub Attribute in Path in the context of patching with add. And that discussion makes sense as the spec is a little vague.

However, with replace, RFC 7644 is quite specific in 3.5.2.3:

   o  If the target location is a multi-valued attribute for which a
      value selection filter ("valuePath") has been supplied and no
      record match was made, the service provider SHALL indicate failure
      by returning HTTP status code 400 and a "scimType" error code of
      "noTarget".

If the valuePath does not match anything, then you need to return 400 noTarget. Microsoft Azure AD SCIM Validator does not appear to expect that reply and expects us to add new entries on replace.
I disagree that:

 o  If the target location path specifies an attribute that does not
      exist, the service provider SHALL treat the operation as an "add".

would change this interpretation as that does not consider the filter; plus the way these are written they get more and more specific as you go down the list.

A specific example:
The current value of emails:

 

 

 "emails": [                     
   {                             
     "type": "work",             
     "value": "some_primary_email",  
     "primary": true             
   }

 

 

and the replace operation:

 

 

"Operations": [{
  "op": "replace",
  "path": "emails[type eq \"home\"].value",
  "value": "some_email"
}]

 

NOTE: values do not show email addresses as those get removed (privacy checker) - so they are replaced with "some_primary_email" and "some_email"

This should fail as there is no email of type = home to replace.

owinoakelo's avatar
owinoakelo
Icon for Microsoft rankMicrosoft
Feb 07, 2023
PatM_Cerberus. The feedback above is correct and our implementation of this capability is not consistent with the standard. We are incorrectly using replace to update multivalued attribute with a filter instead of add. We have this item in our backlog of things to fix. The validator is however supposed to test the compatibility with our provisioning service as is and for that matter an existing scim incorrectness will also show up here. Hope this is clear and to enable the provisioning service to work for your connector, we have to build with the incompatibility in place for now.
  • PatM_Cerberus's avatar
    PatM_Cerberus
    Copper Contributor
    Feb 07, 2023

    owinoakelo Thank you for your fast reply.

    To clarify, are you saying that using PATCH replace to add multi-valued entries is:

    a.) what Azure's SCIM implementation currently does as of Feb 2023 (we have not seen this in practice)

    or

    b.) an issue with the Azure AD SCIM Validator only

     

    If option "a", is this affected by the feature flag _aadOptscim062020_? And if so, does the Validator accept/use those feature flags? (I wasn't able to see a difference with/without the flag after the last update.)

    • owinoakelo's avatar
      owinoakelo
      Icon for Microsoft rankMicrosoft
      Feb 15, 2023

      PatM_Cerberus Yes, the azure provisioning service currently uses replace for patch operations and expects the endpoint to add if needed. That's why the scim validator makes the same request and it supports the capability of the feature flag.

      • PatM_Cerberus's avatar
        PatM_Cerberus
        Copper Contributor
        Feb 16, 2023

        owinoakelo We have been working to allow Azure's specific replace semantics.

        We've noticed when using Schema Discovery, the system now correctly captures that primary is a Boolean.

               phoneNumbers[type eq "work"].primary      boolean

        However, when it replaces phoneNumbers, we're seeing:

        {
  "Operations": [
    {
      "op": "replace",
      "path": "phoneNumbers[type eq \"work\"].value",
      "value": "767.814.5465"
    },
    {
      "op": "replace",
      "path": "phoneNumbers[type eq \"work\"].primary",
      "value": "(974)693-6276 x6968"
    }
  ],
  "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ]
}

         Notice that the boolean primary value is a text string. We specifically have handlers for Azure sending "True" or "False", but this value is not acceptable and we're failing it.

        I believe this is a problem with the Azure AD SCIM Validator, but curious if Azure AD would try to send such a bad value.

        Email values now seem to work properly - we're getting true/false booleans for primary in those.

Resources