SCIM: Support groups and members fields on User and Group

[ndreas]

Is your proposal related to a problem?

We had an issue where a customer wanted to connect Okta to our self-hosted Jackson instance, and only users and groups ended up in Jackson, not memberships. After logging the actual payloads Okta sent, we discovered that the customer's setup only sent POST and PUT requests to the User and Group resources, while a setup done with the SCIM 2.0 Test App in Okta sent PATCH requests to set memberships.

After dumping the payloads sent by Okta, we discovered that the POST and PUT requests had the memberships in the groups and members fields. According to the RFC the groups field on the User resource, and the members field on the Group resource contains the memberships.

Describe the solution you'd like

It would be nice if the groups and members fields in the payloads could be handled in the endpoints for creating and updating:

• https://github.com/boxyhq/jackson/blob/v1.28.2/npm/src/directory-sync/scim/Groups.ts#L56
• https://github.com/boxyhq/jackson/blob/v1.28.2/npm/src/directory-sync/scim/Groups.ts#L123
• https://github.com/boxyhq/jackson/blob/v1.28.2/npm/src/directory-sync/scim/Users.ts#L38
• https://github.com/boxyhq/jackson/blob/v1.28.2/npm/src/directory-sync/scim/Users.ts#L99

Describe alternatives you've considered

We can always ask the customers to exactly follow the instructions for Okta, but since the field is part of the RFC it would be good to support it.

Additional context

I think this may be related as well: https://github.com/boxyhq/jackson/discussions/1614

[deepakprabhakara]

Thanks @ndreas, we'll check this and look to support it if Okta has indeed started sending the right information now for group memberships.