Are you planning to spend time to fix the rate limits handler and decrease the number of allocated workers to avoid Okta rate limit errors?
Every time we deploy any changes in SailPoint that cascade down to Okta we get 429 (rate limits) and “too many concurrent requests” errors in the Okta logs associated to SailPoint’s service account.
I tried to manage the rate limits overflow by lowering the “API Rate Limits” under Aggregation Settings > Additional Settings, but it doesn’t seem to improve a bit.
When I use the Okta APIs with my bulk scripts I never run into these errors because I use a simple trick which is using the x-rate-limit-* headers coming in each API response to calculate whether I need to insert a pause or I can keep going.
Also, although I don’t use multithreading hence, I haven’t run into “too many concurrent requests” errors with my scripts, I would have imagined that SailPoint designed this connector with enough workers to keep high performance standards without clogging the pipe. However, despite Okta’s documentation clearly says it only allows 75 concurrent transactions per org, when I deploy changes to our SailPoint’s identity profile that cascade down to Okta, I see 128 workers trying to work on that sync.
If Okta halting any processing because there are too many concurrent requests, why don’t just limiting the allocated workers to 30 or so to avoid triggering the threshold that clogs the whole thing?
I tried to find the Okta connector in SailPoint’s GitHub repo to submit a pull request with this little trick that would resolve many issues we have with our deployments, but I guess it’s a proprietary component that only SailPoint is able to maintain.
Okta connector already uses all the best practices for mitigating the rate limit concern.
Connector already uses X-Rate-Limit-Limit, X-Rate-Limit-Remaining and X-Rate-Limit-Reset
If the threshold of rate limit is set to 90% in the Okta’s tenant, I would suggest to set the API Rate Limits to 85%.
If still the API call exceeded beyond the limit, you will see the rate limit warning message. Connector already uses whatever way is possible from Okta side. This connector is proprietary component which is developed and managed by SailPoint, so there is no provision for submitting any change request in GitHub.
I lowered the API Rate Limits to 50% a month ago and I still have to monitor our rate limits because of the risk of violation events observed in our Okta tenant.
Also, if the connector was configured to follow best practices, is there any other configuration we’re missing to avoid the thousands of events we observe in Okta whenever SailPoint tries to update our profiles or assign new accesses?
Hi Elisa, please open a support ticket and get it investigated. There might be scenarios where Okta applications are managed for which the threshold limit is low and also the threshold limit in the Okta tenant varies as per the overall tenant setting. Thanks.
I’ve been working with Okta Workforce APIs for a while, and I know it doesn’t really allow much scalability unless requesting temporary increase for rate limits through the appointed CSM for the company, and as a temporary setup shouldn’t be the workaround for handling with a greedy system.
When we released our setup to Prod for the first time, it was a painful 2 days of handling Okta rate limits, which led to false provisioning errors, VAs clogged and long hours to get us through it. We had to revert all the provisioning activities to Okta to allow the other components to settle down, and enabled provisioning 2 weeks later.
Since then, every time we do changes that cascade to Okta show the same behavior in the logs and the cause seems to be the connector is using more workers than the allowed limit.
As you said, this is a proprietary connector, so I’m only guessing the root cause for this problem. If you can pass this feedback to engineering, I would appreciate this a lot.
