Share via

Azure SCIM provisioning Update Group [Add Members] retry is not working

Felix H 26 Reputation points
2023-10-24T13:21:50.7+00:00

We have an issue with Azure SCIM provisioning. When a large number of users (ex: 5000 ) is added to a group, our API receives a massive number of requests and a rate limiting mechanism is activated. As a result some requests (not all) receive HTTP 429 response. Azure considers this update a failure and retries it after a while. The issue is that Azure retries the whole set of updates sending the same number of requests again and that triggers rate limiting again. We need Azure to be more "intelligent" and to retry only those request that actually failed (received HTTP 429). It seems that a similar issue was described here, but was not answered by Microsoft.

There is also a suspicion that Azure is not compliant with RFC 7644. In this page Azure expects HTTP 204 in response to Update Group [Add Members]. However, the RFC 7644, Section 3.5.2 says

On successful completion, the server either MUST return a 200 OK
   response code and the entire resource within the response body,
   subject to the "attributes" query parameter (see Section 3.9), or MAY
   return HTTP status code 204 (No Content) and the appropriate response
   headers for a successful PATCH request.  The server MUST return a 200
   OK if the "attributes" parameter is specified in the request.

We believe this may add to the retry issue.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,632 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Danny Zollner 9,871 Reputation points Microsoft Employee
    2023-10-24T17:25:49.33+00:00

    Since there are a few sub-questions here:

    • There is no way to make Entra SCIM Provisioning apply rate limiting to custom non-gallery applications using SCIM today. Your SCIM server will need to be able to handle the membership changes as they come in. There are a few ways this can be solved and eventually (no ETA, unfortunately) there should be some controls available to help mitigate this sort of issue.
    • 200 and 204 are both acceptable, a 200 response returned on a PATCH will not cause issues. One note, you MUST honor the excludedAttributes=members parameter in the URL, and as a result should not return the members attribute for groups.