Hello,
There are some doubts I have regarding SCIM based user provisioning, Could you please clarify me with those?
Please consider, We are ISV and we want to put our app on OIN.
As per Okta’s Configuring-On-Premises-Provisioning document, If we build SCIM connector(using okta scim server sdk which resides in our org), is it Okay if our client only installs OPP agent behind the firewall of their n/w and they will use our SCIM server URL for user provisioning solution? OR In short, Can I get to know that only OPP agent should be behind the firewall or OPP agent and our SCIM connector also( Both ) should be behind the firewall of client’s network?
If we want to build SCIM(cloud) provisioning solution, How can I test our SCIM connector with Okta? As our SCIM connector is still in development and it is pointing to local domain. I am getting issue No Route To Host from Okta while testing connector configuration . So is there anything we can do that we will be able to test our SCIM connector with Okta locally?
Is it required to create app with Okta’s template? Because I am unable to find any Okta Verified template for SCIM and what differs If I create app manually rather than using template?
Please consider, We are ISV and we want to put our app on OIN.
Could you please help me with this?
Thanks in advance.
For an application to be published in Okta Integration Network, we need the SCIM server to be hosted in cloud and to support SCIM 2.0 operations (POST for create, GET for read, PATCH for update, DELETE for delete, usage of SCIM 2.0 namespaces). On Premises Provisioning agent supports only SCIM 1.1 operations.
If you would like the application to be delivered to multiple customers and support SCIM 1.1 operations, then it’s required to have it deployed behind the firewall, same as the agent. The OPP agent will act as a proxy between Okta and the SCIM connector in order to ensure connectivity.
Thanks for the response and information. As per our requirement, if we want our app to be as a Profile Master(MUST) with SCIM cloud based user provisioning and SSO enabled(our custom ACS url). Is there any way this can be happened? If it’s not, which way provisioning should be implemented so that we can achieve our requirement?
To integrate the application in OIN and have SCIM cloud based user provisioning, SAML SSO and have to option be profile master, then you can do the following:
A SAML application through application integration wizard
A SCIM 2.0 Template app for user provisioning
Submit the applications on oinmanager.okta.com, adding all the necessary details for your application
One of my colleagues from Apps Team will contact you for next steps
At the end of the QA testing, Apps Team will create a new application based on the two provided and publish it in the Okta Integration Network
Please note that your application must be able to generate tenants for each customer and the SAML SSO and SCIM 2.0 provisioning configuration values provided in the Okta preview tenant need to be from one of this tenants.
Hi @dragos,
Thank you so much. This is really helpful and quick, this is what I wanted to ask.
One more thing, I want to create a SCIM 2.0 Template app(OAuth) and the procedure I am following is Application -> Add Application -> Search (SCIM 2.0) -> Add
Is this is the correct way to create SCIM 2.0 Template app? Because through this, I am unable to configure (Authorization endpoint URI & Access token endpoint URI and other deatils) so that we can Authenticate our clients.
and sorry but could you please elaborate in more detail for this? the SAML SSO and SCIM 2.0 provisioning configuration values provided in the Okta preview tenant need to be from one of this tenants.
When using the SCIM 2.0 Template App, you will need to provide an existing bearer token that Okta will use to communicate with your SCIM server. When submitting the application on oinmanager.okta.com, you will be able to provide the authorization server’s details in order for customers to generate automatically a bearer token.
Regarding my previous message, your application must support tenants, such as company1.yourapplication.com, company2.yourapplication.com. The values for SAML (where to upload metadata from Okta) and for SCIM (the authorization server on which the user authenticates in Okta) need to be from one of this tenants, for example oktaintegration.yourapplication.com. Our Applications Team would need access here in order to confirm the integration.