question

JanJancalek-7057 avatar image
0 Votes"
JanJancalek-7057 asked JanJancalek-7057 commented

Azure AD SCIM Provisioning: Repeating requests for Adding Users to Group

Hello,
We have created a SCIM endpoint for our custom application connecting to Azure AD's SCIM client. We have created an Enterprise Application for our custom application and successfully connected the provisioning. We are creating users and groups successfully.
We are using https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#update-group-add-members as reference.
We are succesfully adding users to groups for the first time.

We have now issue, that AD is trying to add users to group again in next provisioning cycle. That ends in error as user is already added. But AD is trying that again and again. How can we prevent that?

AD is always doing GET request before adding user again. But it cannot check if user is already in group, as AD GET request contain "?excludedAttributes=members" and therefore we are not filling members in response. We are never filling members in reponse. Is this correct?
And we should not as stated in Tutorial: Develop and plan provisioning for a SCIM endpoint in Azure Active Directory: It isn't necessary to support returning all the members of the group. Also examples in Tutorial are not containing them.

What is correct response for AD, when user was already added to group?
Currently we are returning: 409 Conflict
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
],
"scimType": "uniqueness",
"detail": "schema validation : ErrorStatus(error=Error adding member to group, summary=, statusCode=400)",
"status": 409
}
Is our response correct? Or could something here be root cause of our problem?

azure-ad-user-provisioning
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

JanJancalek-7057 avatar image
0 Votes"
JanJancalek-7057 answered JanJancalek-7057 commented

Solved it by adding check into SCIM and when SCIM received add member to group for member that is already added, then we return 204 without adding user again.
Maybe not the cleanest solutions, but so far it looks ok.

Ideal solution would be to process it according Microsoft documentation, but that documentation probably does not exists right now.

· 5
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@JanJancalek-7057
I'm glad that you were able to resolve your issue, and thank you for posting your solution here so that others experiencing the same thing can easily find this!

1 Vote 1 ·

The SCIM spec dictates that when using the add operation, if the value is already present then no changes should be made to the resource and a success should be returned. Your solution appears to match what the spec requires.

For reference, this part of the spec is: https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2.1

Specifically:

o If the target location already contains the value specified, no
changes SHOULD be made to the resource, and a success response
SHOULD be returned. Unless other operations change the resource,
this operation SHALL NOT change the modify timestamp of the
resource.

0 Votes 0 ·

@ZollnerD Problem with SCIM spec is that AAD is not implementing all SCIM stuff, so then we were unsure what we have to implement and what not. And microsoft documentation is missing some details about patch.
But thanks for answer, at least it looks we have it resolved correctly. You are probably right, that when something is not clear from Microsoft side, we should use SCIM specification.

0 Votes 0 ·

In general if you implement the SCIM spec as defined in the RFC, you'll have no compatibility problems with Azure AD. A few things (ie: an old issue of us sending active as a string rather than boolean) have to be addressed by using a feature flag included in the URL of your SCIM endpoint, but that's about the only caveat. This specific behavior of how to handle redundant group membership adds is purely server side though.

0 Votes 0 ·
Show more comments