Custom attribute missing in POST only available via PATCH

Anonymous
2020-10-16T16:05:48.247+00:00

Hi,
I added a custom attribute to the SCIM User Provisioning, phoneNumbers[type eq "did"].value and some others and found an issue. When I add a user to the app the custom attribute is not sent through in the POST request. If I re-provision that user the attribute is sent through the PATCH request.

Is this a known issue, or am I missing something.

Thanks,
Kajan

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
21,344 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Danny Zollner 9,971 Reputation points Microsoft Employee
    2020-10-18T02:49:47.383+00:00

    This is a known issue for custom attributes that are not part of the core schema if they aren't added to the provisioning schema in a certain way. Section 3.10 of RFC 7644 (https://tools.ietf.org/html/rfc7644#section-3.10) calls out:

    In general, attributes are uniquely identified
    by prefixing the attribute name with its schema URN separated by a
    colon (":") character; e.g., the core User resource attribute
    'userName' is identified as
    "urn:ietf:params:scim:schemas:core:2.0:User:userName". Clients MAY
    omit core schema attribute URN prefixes but SHOULD fully qualify
    extended attributes with the associated schema extension URN to avoid
    naming conflicts.

    In this case, it's sort of a gray area given that phoneNumbers is a core schema attribute, but the type of "did" isn't explicitly mentioned in RFC 7643. Our provisioning engine I think is being a bit finnicky here as you've added just "phoneNumbers[type eq "did"].value". In instances where an attribute exists in the schema but we can't determine that it's a part of the core schema, there's some additional information(I can't recall the exact logic here) that we need that is returned to us by the SCIM service provider (the non-Azure AD side of this equation), so we can only do that after the object is already created. That in turn is leading to this behavior you're observing where we're not processing some attributes until the second pass after the object is created.

    Try doing urn:ietf:params:scim:schemas:core:2.0:User:userName:phoneNumbers[type eq "did"].value and see if that works.

    1 person found this answer helpful.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.