Things I Learned Provisioning Directly To Okta

Identity Security Cloud (ISC) ISC Community Knowledge Base
, ,
1

The typical provisioning flow for the majority of SailPoint customers involves provisioning directly to Active Directory. Most environments that are using Okta typically sync from AD up to Okta. As a result, very few environments probably provision directly to Okta from SailPoint. (Note: this is a guess, I obviously don’t have stats on this.)

Here are my notes from provisioning directly to Okta.

  1. Use delta aggregations. This isn’t really specific to provisioning, but if you’re doing full aggs against Okta, you’re going to have a bad time. Okta throttles API calls, and their rate limiting means you’re going to have a really bad time if you try to aggregate all your accounts. Like, a very bad time… aggregations will run for a very, very long time. Just use deltas.
  2. Status. Okta has many of these! Unfortunately, SailPoint only has two: active and disable.
    1. SailPoint will create an Okta account in a STAGEDstate (which SailPoint considers disabled). You can include activate in your Create profile and specify a value of true or false to determine whether the account is immediately activated.
    2. Once activated, an account goes into a PROVISIONED state in Okta until the password is set or the account is explicitly activated by an admin, at which point it becomes ACTIVE. Both PROVISIONED and ACTIVE are considered active states by SailPoint.
    3. You can set your connector to set Okta accounts to either SUSPEND or DEPROVISIONED status (both of which are, obviously, considered disabled states in SailPoint) when SailPoint disables the accounts. Unfortunately, this is either/or - you can’t change this on a case-by-case basis, and you can’t have different lifecycle states do different things.
    4. Note that because STAGEDand SUSPEND/DEPROVISIONED are all considered disabled states, SailPoint will not change anything if an Identity gets termed before the Okta account is activated. For example, if you have an account for a new hire provisioned in a STAGED state, but the new hire backs out before their start date so they never get activated, SailPoint won’t change their Okta account to SUSPEND or DEPROVISIONED because as far as SailPoint is concerned, the account is already disabled. You can work around this with a Workflow or in some other way, but this is not out-of-the-box functionality.
  3. Attribute Sync. Okta does not allow modification to accounts in a DEPROVISIONED state. This is a hard-and-fast rule, not something you can change in your Okta settings or SailPoint source configuration. Unfortunately, SailPoint doesn’t give a heck about this limitation at the moment (vote for this Idea to fix that), so it’ll attempt to sync attributes to DEPROVISIONED Okta accounts that are tied to Identities with active or inactive (short-term) lifecycle states. This will inevitably fail with an error, and SailPoint will then retry up to 10 times… per attribute. Depending on how many identities you have, this can cause issues where you have excess items in your IDENTITY-SYNC activity queue.

That’s all I’ve got off the top of my head at the moment, but I’ll be sure to add more as I think of it or as more inevitably comes up! If you’re provisioning directly to Okta from ISC, please add your gotchas below!

5 Likes
2

Would you be able to modify some of this behavior through the use of a SaaS Connector Customizer?

Edit: NVM

image
image907×1038 50.4 KB

1 Like
3

Something I’ve recently learned is that while SailPoint will set the Okta user type on account create, you can’t use attribute sync to update the user type. So if your use case involves an account moving from one type to another, it’s not supported.

1 Like