Azure/EntraID non-compliance with SCIM specification

Question

Azure/EntraID non-compliance with SCIM specification

KT 46

I've noticed two areas where EntraID is not compliant with the SCIM specification. These cause any connection to a SCIM server through EntraID to send requests that may not be handled by the SCIM server unless specifically modified to handle the special cases.

Manager mapping is incorrect in default enterprise application settings

When setting up a new enterprise application, EntraID uses urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager instead of urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.value when mapping managers for a user. This is incorrect, as the SCIM specification states that manager.value is the valid and expected property: https://datatracker.ietf.org/doc/html/rfc7643#section-4.3. This is modifiable in the attribute mappings of the enterprise application, but the default should be compliant with the SCIM specification. SCIM servers should NOT have to handle the incorrect mapping, and users should NOT have to correct the mapping when setting up a new application.

Group member "remove" operations are an incorrect form
The SCIM spec (https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2.2) states that a request removing a member from a group should be of the form:

   PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   If-Match: W/"a330bc54f0671c9"

   {
     "schemas":
      ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
     "Operations":[{
       "op":"remove",
       "path":"members[value eq \"2819c223-7f76-...413861904646\"]"
     }]
   }

with op & path, and the value being removed specified in the path.
However, EntraID's Group member remove requests are in the form that is valid for adding members but not removing. For example, the following request which specifies op, path, and value is valid for adding a member, but not for removing a member:

   PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
   Host: example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   If-Match: W/"a330bc54f0671c9"

   { "schemas":
      ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
     "Operations":[
       {
        "op":"remove",
        "path":"members",
        "value":[
         {
           "display": "Babs Jensen",
           "value": "2819c223-7f76-453a-919d-413861904646"
         }
        ]
       }
     ]
   }

A SCIM server that is compliant with the SCIM specification should not have to handle this special case of request. Requests of this kind could (and should) be considered invalid requests.

Are there any plans to address these breaks from the SCIM specification to allow EntraID to be better supported with regards to SCIM?

1 answer

Your answer

Answer 1

JamesTran-MSFT 37,226 Microsoft Employee Moderator

@KT

Thank you for your detailed post and identifying the two areas you noticed where MS Entra ID is not compliant with the SCIM specification(s).

I've reached out to our SCIM engineering team so they can take a closer look into your issue and will update as soon as possible.

In the meantime, I'll summarize your issue below for my understanding and to ensure I didn't miss anything.

Manager mapping is incorrect in default enterprise application settings.

When setting up a new enterprise application, EntraID uses urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager instead of urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager.value when mapping managers for a user. This is incorrect, as the SCIM specification states that manager.value is the valid and expected property: https://datatracker.ietf.org/doc/html/rfc7643#section-4.3. This is modifiable in the attribute mappings of the enterprise application, but the default should be compliant with the SCIM specification. SCIM servers should NOT have to handle the incorrect mapping, and users should NOT have to correct the mapping when setting up a new application.

Group member "remove" operations are an incorrect form.

The SCIM spec (https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2.2) states that a request removing a member from a group should be of the form.... with op & path, and the value being removed specified in the path. However, EntraID's Group member remove requests are in the form that is valid for adding members but not removing. For example...

Additional Links:

SCIM protocol requests and responses - Example SCIM requests expected responses.
Update Group [Add Members / Remove Members]

I hope this helps!

If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.

KT 46 Reputation points

2023-12-27T19:23:35.4133333+00:00

Thanks for the quick response! Just some extra info, pointing to the docs you provided, this example request for removing a group member is invalid. See Okta's docs for the correct form for add/remove ops: Okta add/remove operations
JamesTran-MSFT 37,226 Reputation points Microsoft Employee Moderator

2023-12-29T19:29:30.7466667+00:00
@KT

Thank you for your time and patience on this!

I received a response from the SCIM engineering team, which I'll share below:

Manager mapping is incorrect in default enterprise application settings - this is a known issue with a fix planned.

Group member "remove" operations are an incorrect form - when it comes to the syntax, this is valid as not every possible permutation of syntactical variation is explicitly listed in the SCIM spec. A syntax that can be used for "add" operations can also be used for replace and remove.

Please note that due to the holidays any responses from the SCIM team to follow up questions will be delayed.

I hope this helps!

If you have any other questions, please let me know. Thank you again for your time and patience on this!

If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
KT 46 Reputation points

2023-12-29T20:54:01.13+00:00
this is valid as not every possible permutation of syntactical variation is explicitly listed in the SCIM spec.

Yes, but the one that is listed is not of this form, and explicitly is not of the same form as the add operation. The spec even states (https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2.2):

The "remove" operation removes the value at the target location specified by the required attribute "path". The operation performs the following functions, depending on the target location specified by "path"

The target location therefore must be in path. Path specifies the specific target to be removed, and if the target is multi-valued (like members)... the spec continues:

If the target location is a multi-valued attribute and no filter is specified, the attribute and all values are removed, and the attribute SHALL be considered unassigned

The form provided by EntraID implies that all members would be removed, as the value attribute is irrelevant. There is further another example provided in the spec that shows a similar request to remove all members of a group with a remove operation where the path is simply members.
The form EntraID uses, and shown in the screenshot provided from the EntraID docs, is invalid and not compliant with the SCIM specification.
JamesTran-MSFT 37,226 Reputation points Microsoft Employee Moderator

2024-01-10T18:23:11.8033333+00:00

@KT
Thank you for following up on this and I apologize for the delayed response! I've reached out to the SCIM engineering team so they can look into your issue and will update as soon as possible. Thank you again for your time and patience on this!

---cc: @Danny Zollner

Share via

Azure/EntraID non-compliance with SCIM specification

1 answer

Your answer