Azure AD SCIM Provisioning content type is not set to application/scim+json

[kwent]

Azure AD SCIM Provisioning content type is not set to application/scim+json

Service: Azure AD
Doc: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#get-user

While testing SCIM and clicking on Test connection button. Request is sent without a content-type set to application/scim+json. Most of application will respond with a 406 Not Acceptable

Started GET "/scim/Users?filter=userName+eq+%227d420df3-9995-4831-a406-ecf8166f5f6a%22" for 40.126.25.32 at 2022-06-09 13:52:57 -0700
Cannot render console from 40.126.25.32! Allowed networks: 216.181.76.143, 47.185.130.74, 73.241.204.197, 127.0.0.0/127.255.255.255, ::1
Processing by Public::Scim::UsersController#index as HTML
  Parameters: {"filter"=>"userName eq \"7d420df3-9995-4831-a406-ecf8166f5f6a\""}
Completed 406 Not Acceptable in 143ms (Views: 4.8ms | ActiveRecord: 0.0ms | Allocations: 163348)

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 271dc426-fb47-7441-d627-ec11f8c7a6ea
• Version Independent ID: 4cb8bfc8-4748-e501-425a-e4c2da0f5f5a
• Content: Tutorial - Develop a SCIM endpoint for user provisioning to apps from Azure Active Directory - Microsoft Entra
• Content Source: articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md
• Service: active-directory
• Sub-service: app-provisioning
• GitHub Login: @kenwith
• Microsoft Alias: kenwith

[JamesTran-MSFT]

@kwent
Thank you for your feedback! To better understand and route your issue, can you share the documentation that you're referencing when creating this issue?

[kwent]

Added the doc. The problem is wider. Any request made by Azure AD to scim endpoints doesn't have content type application/scim+json as referenced in https://datatracker.ietf.org/doc/html/rfc7644#section-3

[ZollnerdMSFT]

Hi - I'm a product manager here at Microsoft and work on our SCIM client and provisioning service. We've looked into this and things are working as expected both by our design and by the requirements of the spec. Key things to call out:

1. The test credentials action you initially reference is a GET - there is no body to the request, therefore no content-type header is required
2. The SCIM protocol spec (RFC 7644) states in section 3.8 that the content type/data format defaults to application/scim+json if no value is provided
3. On requests where our provisioning service does provide a body (i.e.: a POST or PATCH with details being provided in a JSON object in the body) we do include the content-type header, even though it is optional as pointed out above

[JamesTran-MSFT]

@kwent
Since our SCIM client and provisioning service is working as expected, I'll go ahead and close out this issue. If you're still running into problems, I'd recommend working closer with our support team via an Azure support request. Or you can leverage our Q&A forum by posting your issue there so our community, and MVPs can further assist you in troubleshooting your issue or finding potential workarounds.

Thank you again for your time and patience throughout this issue.

[pond]

The test credentials action you initially reference is a GET - there is no body to the request, therefore no content-type header is required

This makes sense and is in line with GET examples in RFC 7644 which contain no Content-Type header in the request, compared with all other examples for other HTTP methods where the header is included. If that's how Azure AD behaves, it should be fine.

The SCIM protocol spec (RFC 7644) states in section 3.8 that the content type/data format defaults to application/scim+json if no value is provided

It's a minor point, but that is incorrect. https://datatracker.ietf.org/doc/html/rfc7644#section-3.8 is clearly talking about the Accept header when it makes that reference. The statement does not apply to Content-Type.

When it comes to Content-Type, the HTTP specification itself talks about that; it's technically not mandatory, but processing systems would have to guess the content type otherwise and default to application/octet-stream if they can't. It seems reasonable to just require and assume that this is the content type inbound when handling SCIM endpoint requests as an API implementor, since a JSON parser used therein has to be robust against potential fuzzing attacks regardless - the presence of the header could hardly be trusted by itself in any case.

On requests where our provisioning service does provide a body (i.e.: a POST or PATCH with details being provided in a JSON object in the body) we do include the content-type header, even though it is optional as pointed out above

Yes, this is good and I'd argue there's almost no excuse for not doing so when consuming SCIM APIs.

Thanks for the detailed explanation.