Okta Group Push via API


#1

Hi,

we are using the recently released Group Push functionality through which you can push groups from Okta to an AD thus making Okta the owner of the group.

What I haven’t found yet is a way to trigger that push via API as we need to do that for more than 1000 groups…

Has anyone figured out if and how it works?

Best regards,
G.


#2

Hello, I have the same problem.

Easiest way is to trigger admin panel private API. Be careful with that as private API’s are for internal use only and can change without any notice as well as harm your instance if used with errors.

In my case it looks like:

curl ‘https://{{tenant-admin}}.okta.com/api/internal/instance/{{appId}}/grouppush/{{mappingId}}’
-H ‘Cookie: {{cookies}}’
-H ‘Origin: https://{{tenant-admin}}.okta.com’
-H ‘Accept-Encoding: gzip, deflate, br’
-H ‘X-Okta-XsrfToken: {{token}}’
-H ‘Accept-Language: en-US,en;q=0.9,ru;q=0.8’
-H ‘User-Agent: {{userAgent}}’
-H ‘Content-Type: application/json’
-H ‘Accept: application/json, text/javascript, /; q=0.01’
-H ‘Referer: https://{{tenant-admin}}.okta.com/admin/app/{{appName}}/instance/{{appId}}/’
-H ‘X-Requested-With: XMLHttpRequest’
-H ‘Connection: keep-alive’
–data-binary ‘{“action”:“PUSH”}’
–compressed


#3

Hi Andrey,

thanks for this!
First time I hear about this. Do you know if there is any documentation on that? Just googled it but couldn’t find anything.
Apart from making sure not to cause any harm, I’m wondering what values I would populate
{{cookies}}
{{userAgent}}
with.
And how do you get the group’s {{mappingId}}?
Thanks a lot!
Best regards,
G.


#4

Also interested in other private API functions


#5

Private APIs are not documented publicly.

{{cookies}}, {{userAgent}}, {{mappingId}} are your own cookie, browser userAgent and group mappingId from your tenant.

You can use Chrome DevTools to track these fields and copy necessary data to Postman or curl. Just check there what is happening when you do click on ‘Push now’ button in Okta UI.


#6

Hi Andrey,

I’ve been making some progress here in finding the needed values but I still haven’t managed to make it work.
Looking at the values what strikes me as odd is the following:

  • {{mappingId}} is always a different string when I do group pushes in the front-end. Seems like this number is generated AFTER the group push is done and either refers to the mapping between the Okta group and the AD group, or the AD group’s ID. In other words

  • so I tried to populate the group’s Okta ID instead of a mapping ID but then wondered how should the AD in which OU to push the group (this is normally selected manually when pushing the group in the front-end)

  • so I guessed that maybe the {{mappingId}} is in fact the OU ID provided by the AD, but again, the number is always different even if I choose the same group and OU to push it to

So I figured in the CURL parameters we’d have to specify at least 2 Okta IDs - the group ID and the OU ID.
When you submit your CURL statement in your environment, in which OU is the group created? In the root OU?

Thanks,
G.


#7

Hello geppe,

I have group push configured for Jira app and not AD. With Jira mappingID is unique ID for every groups I have pushed: group1->to_Jira has one mappingID, group2_to_Jira has another.