Skip to content

Support for MS Azure requests

Jump to bottom
Pascal Knüppel edited this page Nov 2, 2023 · 6 revisions

In the last time I got several tickets about failing requests initiated by MS Azure. These requests do not follow the SCIM-specificiation but I added some workarounds to make them work. This section will shortly describe what the problem is and what was done to support these requests.

Support limitation

I added only as much workaround support as needed not as much as possible. So far I do only support these cases that were directly addressed by issues. The following sections will mention what is supported and what is not.

patch remove-requests from Azure

The patch definition for remove operations is defined here: https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2.2

MS Azure sends patch-remove requests that point to specific values with filters in the following form:

PATCH /scim/Groups/2752513

{
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
     "Operations": [
         {
             "op": "Remove",
             "path": "members",
             "value": [
                 {
                     "value": "2392066"
                 }
             ]
         }
     ]
}

This is an incorrect setup for a delete request. The correct setup would look like this:

{
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
     "Operations": [
         {
             "op": "Remove",
             "path": "members[value eq \"2392066\"]"
         }
     ]
}

The SCIM-SDK analyzes the request before it is evaluated and notices if a value is set within the remove-operation. It then rebuilds the original request to the correct representation that will eventually be executed.

multiple values in request

If the request from MS Azure contains multiple values they will be treated as if they were an or-expression filter e.g. members[value eq "1" or value eq "2"]. There is no possibilty to support and-expressions or other comparators than eq in this manner.

example:

{
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
     "Operations": [
         {
             "op": "Remove",
             "path": "members",
             "value": [
                 { "value": "1" },
                 { "value": "2" },
             ]
         }
     ]
}

evaluates to

{
     "schemas": [
         "urn:ietf:params:scim:api:messages:2.0:PatchOp"
     ],
     "Operations": [
         {
             "op": "Remove",
             "path": "members[value eq \"1\" or value eq \"2\"]"
         }
     ]
}

These are the only supported cases for remove. I did not add support for complex or multivalued attributes here.

patch resource add/replace operations

The patch operations for add and replace in the cases when the path-attribute is missing is defined in the following locations:

Ms Azure builds illegal patch requests for values placed in resource-extensions in the following form:

{
    "Operations": [
        {
            "op": "replace",
            "value": {
                ...
                "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber": "1111"
            }
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

this violates the definition of RFC7644 because the value is expected to represent the resource itself. Thus the request should look like this:

{
    "Operations": [
        {
            "op": "replace",
            "value": {
                ...
                "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
                    "employeeNumber": "1111"
                 }
            }
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

Rebuilding of add/replace requests

The SCIM-SDK iterates over the attributes and will inject the values of the request-resource one by one into the original-resource. It will detect the attribute style definition that is used by MS Azure and will rebuild the value-node into its correct form of:

"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
   "employeeNumber": "1111"
}

Like this the SCIM-SDK can operate normally and it will add/replace the value in its correct position.

Supported cases

The support for direct resource-value insertion as MS Azure represents it is limited to resource-extensions. The following listed forms are supported. All other variations will be rejected:

  • "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber": "1111"
  • "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager": {"value": "1111"}
  • "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.value": "1111"

Support for MsAzure outer-bracket filter notation

MsAzure uses the following filter-notation that is not defined by SCIM: emails[primary eq true].value eq "[email protected]" SCIM would require this kind of expression to be expressed like one of these representations:

emails[primary eq true and value eq "[email protected]"]
of
emails.primary eq true and emails.value eq "[email protected]"

The MsAzure expression is automatically resolved to a logical and-operation to match the correct results. It is not needed to activate this workaround explicitly it is supported without doing any configurations.

Clone this wiki locally