Forum Discussion

owinoakelo's avatar
owinoakelo
Former Employee
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
owinoakelo's avatar
owinoakelo
Former Employee
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 _https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/application-provisioning-config-problem-scim-compatibility_? 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
    Former Employee
    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.

      • owinoakelo's avatar
        owinoakelo
        Former Employee
        Feb 22, 2023

        PatM_Cerberus , you are right. This is an issue with the SCIM validator. The Azure code base will respond with a Boolean as expected. We have added this in our backlog of fixes and will address it. Thanks for highlighting this.

Resources