Hub and Spoke sounds applicable to your setup. I just implemented something similar without the AD component. Per Okta’s multi-tenancy documentation and marketing materials, the upstream org/origin of the authentication is the spoke and the downstream/target org is the hub.
In your case, it sounds like the Workforce/Active Directory org is the spoke and the CIAM org is the hub. This is how it was in my setup as well, which seems exactly backwards from how I visualize the architecture. I, as an employee, start in the enterprise SSO Okta org for authenticating to everything, which seems to make it the hub. If I branch from the central starting point to a target app, that is the spoke. But Okta seems to be designing for multiple identity provider entry points to arrive at the same target app, making the target the hub.
To sum up:
Workforce AD authentication → setup Org2Org connector targeting the CIAM org
CIAM org → setup SAML IDP accepting authentication from the Workforce AD org
If you want to enable provisioning, create a SUPER_ADMIN API token in the CIAM org and paste it into the Workforce AD Org2Org settings page.
Edit to add: the directions that were the most clear to me were the (?) help tooltip in the Org2Org app configuration page on the upstream tenant. That will link out to a page that will fill in some variables based on your actual organizations. The only thing to watch out for is if you have a custom domain configured on the target/hub tenant, as the custom domain will be used for the generated configuration settings. In my case, we wanted the default Okta domain and not the custom domain in the SAML config.