Okta SCIM w/ Groups sends multiple conflicting Webhooks?

[devongermano]

Hello all!

I've been working on integrating BoxyHQ Jackson (the service not the library) with Okta using SCIM 2.0 and have come across an unexpected behavior that I'm hoping to get some insight on.

I've set up a group in Okta with a member user_a.
Upon adding another user (user_b) to this group, I am receiving two webhook events.
The first event (group.updated) has both user_a and user_b in the members array, which is expected.

However, the second event (also group.updated) only has user_b in the members array, which is unexpected.

Interestingly, if I use the "Push Now" button in Okta (under Push Groups) after I make changes to my Group, the expected event that contains both user_a and user_b is pushed to my application.

1. Has anyone else experienced similar behavior when integrating with Okta?
2. Are there any specific configurations or considerations in Jackson that might affect how group membership updates from Okta are processed?
3. Is this behavior expected, or could it be a result of a misconfiguration or a known issue?

[devkiran]

I did a quick test on Jackson with Okta.

Okta doesn't always send all members to the group.updated event. This is expected behaviour from Okta. The raw attribute is all the data that Okta sends for each event.

Instead, the recommended way is to listen for group membership changes using the group.user_added and group.user_removed events. And update your database based on these events.

Don't rely on the group.updated event to get the members.

[devongermano]

The part I’m curious about, is that Jackson never sends a group.user_added or group.user_removed event to my web hook endpoint when I add or remove users. I only ever receive a group.updated event.

…

On Mon, Sep 18, 2023 at 10:59 PM Kiran K ***@***.***> wrote: I did a quick test on Jackson with Okta. Okta doesn't always send all members to the group.updated event. This is expected behaviour from Okta. The raw attribute is all the data that Okta sends for each event. Instead, the recommended way is to listen for group membership changes using the group.user_added and group.user_removed events. And update your database based on these events. Don't rely on the group.updated event to get the members. — Reply to this email directly, view it on GitHub <#1614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEI65E2TXC5SULAWFC4MN5DX3EYDNANCNFSM6AAAAAA45N6B74> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[devkiran]

Interesting. I’m not sure why that would be. Can you try the following workflow:

• Create a new group group-1
• Add a user user-1 to group-1
• Under Assignments tab, assign user-1 to the app.
• Under Push Groups tab, search group-1 and click Save

See if you get a group.user_added event.

[devongermano]

No dice... Is there some config or something I'm missing?

[devongermano]

For context, here's the only events I currently recieve:

[devkiran]

I followed the above workflow and received the following events in the order: user.created, group.created, group.user_added.

No particular configuration is required for this to work if I remember correctly. Did you follow the guide to set up the SCIM app on Okta https://boxyhq.com/docs/directory-sync/providers/okta ?

Please make sure that you're using the Okta app SCIM 2.0 Test App (Oauth Bearer Token)

[devongermano]

Could you provide some additional clarity on using the Test SCIM application inside of Okta? Does it have some kind of "okta-magic" built in, that I'm somehow missing in my own application configuration? I have multiple different companies already using SCIM via the Provisioning tab in their Okta instances via the application configuration screen for our application. I've been attempting to integrate the way groups work, with our own internal model for groups, so that companies could manage their groups directly in their IDP instead of our application. Long story short, I can't have them install an additonal test application for handling SCIM when SCIM has already been configured for our actual application.

[devkiran]

I tested the SCIM provisioning with our existing SAML app, and I can verify Okta doesn't send requests for group membership updates.

There is an issue on the Okta dev forum that seems to indicate this is a known issue with Okta: https://devforum.okta.com/t/scim-group-put-request-sends-lots-of-empty-member-objects-why/18313

Let's think about a workaround for this. I'll update the issue with any progress.

[devkiran]

We're thinking about a potential solution for this. We'll keep you posted.

[devkiran]

We did some more testing with the SAML app, but unfortunately, Okta doesn't seem to send the group membership requests. The only way to get the group membership is to use a dedicated SCIM app. Let me know if you have any questions about this.