Closed kwent closed 2 years ago
@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?
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
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
@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.
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.
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 toapplication/scim+json
. Most of application will respond with a406 Not Acceptable
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.