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.
<client company> Okta
idpuser.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.Click Finish. Once created, copy the following info and forward it to the client:
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 2.
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>_IDP
CXNC_PROD_<TENANT_ID>
application<client company> Okta