PATCH /Groups send username information on members

Question

Hi

I am workin on a SCIM integration from Azure to a 3rd party application, the SCIM server code I am using requires two value for every member specified (value (user's id) and display (user's username)). Same as the example provided in the SCIM 2.0 spec https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2.1

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":"add",
        "path":"members",
        "value":[
         {
           "display": "Babs Jensen",
           "$ref":
   "https://example.com/v2/Users/2819c223...413861904646",
           "value": "2819c223-7f76-453a-919d-413861904646"
         }
        ]
       }
     ]
   }

However Azure sends only member.value (user's id) as following:

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

I tried to accomplish this behavior in Azure (sending both "value" and "display" fields) playing with custom attributes but as for now I could not do it. Any idea how could I accomplish this?

Answer 1

This isn't possible with AAD Provisioning and honestly shouldn't be needed. The inclusion of "display" as a sub-attribute on the members attribute in examples in 7644 is almost surely an error. If we look at RFC 7643, the core schema RFC for SCIM, we have a few things that help here:

https://datatracker.ietf.org/doc/html/rfc7643#page-26

 members
      A list of members of the Group.  While values MAY be added or
      removed, sub-attributes of members are "immutable".  The "value"
      sub-attribute contains the value of an "id" attribute of a SCIM
      resource, and the "$ref" sub-attribute must be the URI of a SCIM
      resource such as a "User", or a "Group".  The intention of the
      "Group" type is to allow the service provider to support nested
      groups.  Service providers MAY require clients to provide a
      non-empty value by setting the "required" attribute characteristic
      of a sub-attribute of the "members" attribute in the "Group"
      resource schema.

https://datatracker.ietf.org/doc/html/rfc7643#page-69

In the first link, the relevant part is what I've quoted - it describes the three sub-attributes value, $ref and type. On page 69 we then have the SCIM JSON schema representation of the group schema, and again only the three sub-attributes value, $ref and type are described.

There isn't any benefit that I can identify from requiring both the id value (to members.value) and the display/displayName of a group member. The id value points unequivocally to a single SCIM resource, and the inclusion of a display sub-attribute value wouldn't improve accuracy.

I've seen some SCIM implementations that have members.display, likely influenced by the same examples in RFC 7644 that you've seen and linked to, but generally those are readOnly and are only intended to be helpful for reviewing the group membership list without having to cross-reference each member.value id value to another resource in order to determine what it is. I haven't encountered any SCIM implementations that require members.display while adding a value to members.

AAD Provisioning can't do this today, and given what I just described regarding the validity of any such requirement as far as the SCIM spec is concerned, I don't foresee this changing anytime soon. The SCIM server's developers should change their requirements.