You can use the Okta Org2Org integration to authenticate and optionally provision users from a source Okta org to a target org. The integration is installed and configured in the source org. You can use Okta Org2Org to connect multiple source orgs to a single Okta target org. This integration enables the source orgs to push users to the target org.
A common scenario where Org2Org is used is the hub-and-spoke model. In these scenarios, the spoke orgs are the source orgs and the hub org is the target org.
{info} Source: https://help.okta.com/en-us/content/topics/provisioning/org2org/org2org-integrate.htm
This is the start of the "hub" or target Okta configuration, i.e. Chemaxon's production Okta tenant (sometimes called "Customer Okta", but not to be confused with the Customer's own Okta tenant).
A SAML 2.0 identity provider is created. The name given is important, as it will be seen by users on the login screen, and should be recognizable by them. Suggested name is <client company> Okta
Following the configuration, the Hub ACS URL and audience URI are forwarded to the client, because they need to finalize their Okta Org2Org configuration with it.
CXNC_PROD_<TENANT_ID>_IDP_USERS<client company> Oktaidpuser.subjectNameId. (If the Customer is not using email addresses as the subject name, this may need re-configuring.)CXNC_PROD_<TENANT_ID>_IDP_USERS.cert extension, simply rename it to .pem and the upload should work.This is the spoke part of the hub-and-spoke configuration, or in other words, source Okta. The Customer, in their own Okta tenant, adds an Okta "Org2Org" application. The suggested name should be "Chemaxon Cloud" or "Chemaxon Cloud (Staging)", as appropriate.
Users on Customer side will need to be allocated to this application in order for the integration to work. The details of this belong to the Customer's IT, but our recommendation would be to create an Okta group, assign this group to the Org2Org application, and then assign users to this group as appropriate.
Chemaxon Cloud or Chemaxon Cloud (environment name)
https://okta.chemaxon.com/This is the final action on Chemaxon's side for configuring the IdP. ln order for Okta to offer the Customer's identity provider as a login option, a Routing Rule needs to be configured.
This routing rule states that if the user is trying to access the specific Okta application that was created above, i.e. the Terminus tenant, then the usable IdPs are "Okta" (self / Chemaxon's Customer Okta) and the Customer IdP created in step 1.
This leads to both Chemaxon's Okta and the Customer's Okta being available on the login screen.
{warning} Note / risk: these routing rules are ordered. It is quite possible for a broad rule to have a higher priority than our specific tenant-level rules, and thereby override our rules. It is also quite possible to break many routing rules by adding such an "early catch-all" rule. It is also possible to add a new routing rule at such a position (i.e. as the last one) that it will never be triggered, since it is after a "catch-all rule". The general recommendation is to add routing rules for external IdPs at the top of the list.
CXNC_PROD_<TENANT_ID>_IDPCXNC_PROD_<TENANT_ID> application<client company> OktaConfiguration is now complete. If the configuration has also been completed on Chemaxon's side (likely), then the integration should work. It can be tested by logging in to one of the Chemaxon products in your Chemaxon Cloud tenant.