We will be providing our customers the ability to provision users with us and we will then in turn import those users to our Okta tenant. When the user is removed from their idp we deactivate the account. This brings up a question for me, how do I support customers wanting to no longer use SSO & SCIM without deactivating every account? Right now if they simply remove all of their users from our SCIM server, all of their accounts will be deactivated, and they would have to work with our support to reactivate them. Is it possible to support this scenario in an automated fashion?
My first thought was remove the app user on the SP side and then hit our SCIM server to delete the user, all triggered by the SSO integration being deactivated. Curious if there is a more automated or Okta supported approach.
Hi @quantumew
If I understand correctly, you have a SCIM interface which creates the users in your Okta tenant.
What is the current process, step by step, when a user is removed from the IDP? How does the SCIM interface interact with the Okta APIs?
1 Like
Hey @dragos,
Correct, when a user is removed from the customer’s IdP generally the user is deleted or set to active false in our SCIM server, contingent on the IdP. When we pull that update in to Okta we choose to deactivate the account. The situation I am referring to is a customer that deactivates their entire SSO integration with us. We want to maintain their accounts as active accounts but no longer manage them with SCIM. The distinction is we want our customers to have the ability to remove users from their App integrating with us and ensure the account that was removed, gets deactivated. We also want customers to be able to turn off SSO and go back to basic auth without having to contact us to activate a bunch of accounts. Hopefully that answers the questions you posed.
Hi @quantumew
You can leverage several custom attributes inside the Okta user profile for users, for example isSCIMConnected and isSCIMActive. When the SCIM server queries Okta, based on this attributes, you can choose to display or not the user and set the user to be either active or not.
Based on this attributes, the logic behind the SCIM interface would need to take into consideration the use-cases that you are trying to achieve.
1 Like
Thanks @dragos ! Good to know those properties exist. I am not sure I follow how that would exactly work, “When SCIM Server queries Okta”. Our customer’s IdPs pushes users to our SCIM server and Okta queries SCIM to import the users. Our SCIM server never makes a request to Okta. I might be missing something there.
Hi @quantumew
Through my previous message I was referring to custom attributes that you would create in the Okta profile for your users and then update them through API and leverage them inside the SCIM interface.
1 Like
Oh I see what you mean now, thanks for the clarification @dragos. Thanks again for your expert insight!
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.