Forum Discussion

owinoakelo's avatar
owinoakelo
Brass Contributor
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
alexjones's avatar
alexjones
Copper Contributor
Jul 20, 2023

Hi there,

 

I've been running the SCIM validator against my endpoint and have spotted something that I believe may be a bug, but would like to confirm on here.

 

I'm using the discover schema functionality, my schema gets discovered and in the mappings i'm shown the following:

 

With the JSON from my '/Schemas' endpoint returning the following for the 'primary' sub attribute on 'phoneNumbers':

{
...
    "name": "primary",
    "type": "boolean",
...
}

 

When I run the SCIM validator, I can see that the validator is sending the following value for a 'phoneNumber' when adding a User through POST

 

{
    "type": "work",
    "value": "1-227-170-3259 x696",
    "primary": "(882)058-8632 x34575"
}

 

As you can see, the primary property is a string. This doesn't appear to be the case for the 'primary' property in the 'emails' array in the same request

 

{
    "type": "work",
    "value": "email address removed for privacy reasons",
    "primary": true
}

 

For a bit more detail, emails in the schema discovery mapping screen shows the following:

 

 

And my '/Schemas' endpoint returns the following for the 'primary' sub attribute for the emails array:

{
...
    "name": "primary",
    "type": "boolean",
...
}

 

 

Any help would be greatly appreciated

 

owinoakelo's avatar
owinoakelo
Brass Contributor
Jul 20, 2023

alexjones You are right. We have an issue with the 'phoneNumber' 'primary' attribute which should be sent as a Boolean, but SCIM Validator sends it as string, ignoring the schema. We have this captured in our backlog of issues to be addressed this quarter (ending in September)

  • alexjones's avatar
    alexjones
    Copper Contributor
    Aug 01, 2023

    owinoakelo 

     

    Hi Owino,

     

    I just have a couple of questions on some of the PATCH operations in the SCIM validator.

     

    Should the following PATCH operation be allowed?

    {
    "op": "replace",
    "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager",
    "value": ""
}


    This looks like it should be a 'remove' operation to me. We're currently running into an issue around the value being empty due to validation in our implementation for 'replace' operations. 

     

    Should the following mapping exist in the defaults?

    roles[primary eq "True"].display

     

    Primary is a boolean attribute and is expected to be a string in the filter here. In addition to this, the initial create request doesn't contain any roles. This means when that even when the filter does include a boolean and the filter is ran, there is no role for primary and so the value for the 'type' attribute cannot be replaced.

    {
    "op": "replace",
    "path": "roles[primary eq true].type",
    "value": "I6T3MZAC1HXV"
}


    What's the intention of the following PATCH operation?

     

    {
    "op": "add",
    "path": "emails[type eq \"work\"].value",
    "value": "email address removed for privacy reasons"
}

     

    In the SCIM validator this example has the same issue as the previous, where there are no emails in the initial create request and so the filter fails to find an email to add a 'value' to. I wanted to double check that the intention of the request wasn't to add an email like the following

     

    {
    "type": "work",
    "value": "email address removed for privacy reasons"
}

     

    I understand there are a few issues here, any help will be greatly appreciated! Thanks!

  • alexjones's avatar
    alexjones
    Copper Contributor
    Jul 24, 2023

    owinoakelo 

     

    Brilliant, thanks for your response.

     

    Is the issue backlog publicly available? Be it read-only or otherwise?

     

    I had another couple of questions but don't want to raise them if they've already been raised before

Resources